1. 26 4月, 2007 3 次提交
  2. 20 3月, 2007 1 次提交
  3. 15 2月, 2007 2 次提交
    • E
      [PATCH] sysctl: remove insert_at_head from register_sysctl · 0b4d4147
      Eric W. Biederman 提交于
      The semantic effect of insert_at_head is that it would allow new registered
      sysctl entries to override existing sysctl entries of the same name.  Which is
      pain for caching and the proc interface never implemented.
      
      I have done an audit and discovered that none of the current users of
      register_sysctl care as (excpet for directories) they do not register
      duplicate sysctl entries.
      
      So this patch simply removes the support for overriding existing entries in
      the sys_sysctl interface since no one uses it or cares and it makes future
      enhancments harder.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b4d4147
    • E
      [PATCH] sysctl: x25: remove unnecessary insert_at_head from register_sysctl_table · b402f06d
      Eric W. Biederman 提交于
      There has not been much maintenance on sysctl in years, and as a result is
      there is a lot to do to allow future interesting work to happen, and being
      ambitious I'm trying to do it all at once :)
      
      The patches in this series fall into several general categories.
      
      - Removal of useless attempts to override the standard sysctls
      
      - Registers of sysctl numbers in sysctl.h so someone else does not use
        the magic number and conflict.
      
      - C99 conversions so it becomes possible to change the layout of
        struct ctl_table without breaking everything.
      
      - Removal of useless claims of module ownership, in the proc dir entries
      
      - Removal of sys_sysctl support where people had used conflicting sysctl
        numbers. Trying to break glibc or other applications by changing the
        ABI is not cool.  9 instances of this in the kernel seems a little
        extreme.
      
      - General enhancements when I got the junk I could see out.
      
      This patch:
      
      Since x25 uses unique binary numbers inserting yourself at the head of the
      search list for sysctls so you can override already registered sysctls is
      pointless.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b402f06d
  4. 13 2月, 2007 1 次提交
  5. 11 2月, 2007 1 次提交
  6. 09 2月, 2007 3 次提交
  7. 24 1月, 2007 1 次提交
  8. 09 1月, 2007 1 次提交
  9. 04 1月, 2007 1 次提交
  10. 01 7月, 2006 1 次提交
  11. 30 4月, 2006 1 次提交
  12. 22 3月, 2006 4 次提交
  13. 12 1月, 2006 1 次提交
  14. 07 1月, 2006 1 次提交
    • S
      [X25]: Fix for broken x25 module. · a20a8554
      Shaun Pereira 提交于
      When a user-space server application calls bind on a socket, then in kernel
      space this bound socket is considered 'x25-linked' and the SOCK_ZAPPED flag
      is unset.(As in x25_bind()/af_x25.c).
      
      Now when a user-space client application attempts to connect to the server
      on the listening socket, if the kernel accepts this in-coming call, then it
      returns a new socket to userland and attempts to reply to the caller.
      
      The reply/x25_sendmsg() will fail, because the new socket created on
      call-accept has its SOCK_ZAPPED flag set by x25_make_new().
      (sock_init_data() called by x25_alloc_socket() called by x25_make_new()
      sets the flag to SOCK_ZAPPED)).
      
      Fix: Using the sock_copy_flag() routine available in sock.h fixes this.
      
      Tested on 32 and 64 bit kernels with x25 over tcp.
      Signed-off-by: NShaun Pereira <pereira.shaun@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a20a8554
  15. 04 1月, 2006 2 次提交
    • C
      [NET]: Add a dev_ioctl() fallback to sock_ioctl() · b5e5fa5e
      Christoph Hellwig 提交于
      Currently all network protocols need to call dev_ioctl as the default
      fallback in their ioctl implementations.  This patch adds a fallback
      to dev_ioctl to sock_ioctl if the protocol returned -ENOIOCTLCMD.
      This way all the procotol ioctl handlers can be simplified and we don't
      need to export dev_ioctl.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5e5fa5e
    • E
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet 提交于
      I noticed that some of 'struct proto_ops' used in the kernel may share
      a cache line used by locks or other heavily modified data. (default
      linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
      least)
      
      This patch makes sure a 'struct proto_ops' can be declared as const,
      so that all cpus can share all parts of it without false sharing.
      
      This is not mandatory : a driver can still use a read/write structure
      if it needs to (and eventually a __read_mostly)
      
      I made a global stubstitute to change all existing occurences to make
      them const.
      
      This should reduce the possibility of false sharing on SMP, and
      speedup some socket system calls.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90ddc4f0
  16. 30 8月, 2005 3 次提交
  17. 12 7月, 2005 1 次提交
    • S
      [NET]: move config options out to individual protocols · 6a2e9b73
      Sam Ravnborg 提交于
      Move the protocol specific config options out to the specific protocols.
      With this change net/Kconfig now starts to become readable and serve as a
      good basis for further re-structuring.
      
      The menu structure is left almost intact, except that indention is
      fixed in most cases. Most visible are the INET changes where several
      "depends on INET" are replaced with a single ifdef INET / endif pair.
      
      Several new files were created to accomplish this change - they are
      small but serve the purpose that config options are now distributed
      out where they belongs.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a2e9b73
  18. 23 6月, 2005 2 次提交
    • S
      [X25]: Fast select with no restriction on response · ebc3f64b
      Shaun Pereira 提交于
      This patch is a follow up to patch 1 regarding "Selective Sub Address
      matching with call user data".  It allows use of the Fast-Select-Acceptance
      optional user facility for X.25.
      
      This patch just implements fast select with no restriction on response
      (NRR).  What this means (according to ITU-T Recomendation 10/96 section
      6.16) is that if in an incoming call packet, the relevant facility bits are
      set for fast-select-NRR, then the called DTE can issue a direct response to
      the incoming packet using a call-accepted packet that contains
      call-user-data.  This patch allows such a response.  
      
      The called DTE can also respond with a clear-request packet that contains
      call-user-data.  However, this feature is currently not implemented by the
      patch.
      
      How is Fast Select Acceptance used?
      By default, the system does not allow fast select acceptance (as before).
      To enable a response to fast select acceptance,  
      After a listen socket in created and bound as follows
      	socket(AF_X25, SOCK_SEQPACKET, 0);
      	bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
      but before a listen system call is made, the following ioctl should be used.
      	ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
      Now the listen system call can be made
      	listen(call_soc, 4);
      After this, an incoming-call packet will be accepted, but no call-accepted 
      packet will be sent back until the following system call is made on the socket
      that accepts the call
      	ioctl(vc_soc,SIOCX25SENDCALLACCPT);
      The network (or cisco xot router used for testing here) will allow the 
      application server's call-user-data in the call-accepted packet, 
      provided the call-request was made with Fast-select NRR.
      Signed-off-by: NShaun Pereira <spereira@tusc.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebc3f64b
    • S
      [X25]: Selective sub-address matching with call user data. · cb65d506
      Shaun Pereira 提交于
      From: Shaun Pereira <spereira@tusc.com.au>
      
      This is the first (independent of the second) patch of two that I am
      working on with x25 on linux (tested with xot on a cisco router).  Details
      are as follows.
      
      Current state of module:
      
      A server using the current implementation (2.6.11.7) of the x25 module will
      accept a call request/ incoming call packet at the listening x.25 address,
      from all callers to that address, as long as NO call user data is present
      in the packet header.
      
      If the server needs to choose to accept a particular call request/ incoming
      call packet arriving at its listening x25 address, then the kernel has to
      allow a match of call user data present in the call request packet with its
      own.  This is required when multiple servers listen at the same x25 address
      and device interface.  The kernel currently matches ALL call user data, if
      present.
      
      Current Changes:
      
      This patch is a follow up to the patch submitted previously by Andrew
      Hendry, and allows the user to selectively control the number of octets of
      call user data in the call request packet, that the kernel will match.  By
      default no call user data is matched, even if call user data is present. 
      To allow call user data matching, a cudmatchlength > 0 has to be passed
      into the kernel after which the passed number of octets will be matched. 
      Otherwise the kernel behavior is exactly as the original implementation.
      
      This patch also ensures that as is normally the case, no call user data
      will be present in the Call accepted / call connected packet sent back to
      the caller 
      
      Future Changes on next patch:
      
      There are cases however when call user data may be present in the call
      accepted packet.  According to the X.25 recommendation (ITU-T 10/96)
      section 5.2.3.2 call user data may be present in the call accepted packet
      provided the fast select facility is used.  My next patch will include this
      fast select utility and the ability to send up to 128 octets call user data
      in the call accepted packet provided the fast select facility is used.  I
      am currently testing this, again with xot on linux and cisco.  
      Signed-off-by: NShaun Pereira <spereira@tusc.com.au>
      
      (With a fix from Alexey Dobriyan <adobriyan@gmail.com>)
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb65d506
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4