1. 01 Nov, 2007 1 commit
  2. 10 Oct, 2007 2 commits
    • Eric W. Biederman's avatar
      [NET]: Make device event notification network namespace safe · e9dc8653
      Eric W. Biederman authored
      Every user of the network device notifiers is either a protocol
      stack or a pseudo device.  If a protocol stack that does not have
      support for multiple network namespaces receives an event for a
      device that is not in the initial network namespace it quite possibly
      can get confused and do the wrong thing.
      To avoid problems until all of the protocol stacks are converted
      this patch modifies all netdev event handlers to ignore events on
      devices that are not in the initial network namespace.
      As the rest of the code is made network namespace aware these
      checks can be removed.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric W. Biederman's avatar
      [NET]: Make socket creation namespace safe. · 1b8d7ae4
      Eric W. Biederman authored
      This patch passes in the namespace a new socket should be created in
      and has the socket code do the appropriate reference counting.  By
      virtue of this all socket create methods are touched.  In addition
      the socket create methods are modified so that they will fail if
      you attempt to create a socket in a non-default network namespace.
      Failing if we attempt to create a socket outside of the default
      network namespace ensures that as we incrementally make the network stack
      network namespace aware we will not export functionality that someone
      has not audited and made certain is network namespace safe.
      Allowing us to partially enable network namespaces before all of the
      exotic protocols are supported.
      Any protocol layers I have missed will fail to compile because I now
      pass an extra parameter into the socket creation code.
      [ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 08 May, 2007 1 commit
  4. 25 Apr, 2007 4 commits
  5. 11 Feb, 2007 1 commit
  6. 08 Feb, 2007 2 commits
  7. 03 Jan, 2007 1 commit
  8. 30 Jun, 2006 1 commit
  9. 22 Mar, 2006 4 commits
  10. 11 Jan, 2006 1 commit
  11. 06 Jan, 2006 1 commit
    • Shaun Pereira's avatar
      [X25]: Fix for broken x25 module. · a20a8554
      Shaun Pereira authored
      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: default avatarShaun Pereira <pereira.shaun@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  12. 03 Jan, 2006 2 commits
    • Christoph Hellwig's avatar
      [NET]: Add a dev_ioctl() fallback to sock_ioctl() · b5e5fa5e
      Christoph Hellwig authored
      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: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet authored
      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
      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: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 29 Aug, 2005 1 commit
  14. 22 Jun, 2005 2 commits
    • Shaun Pereira's avatar
      [X25]: Fast select with no restriction on response · ebc3f64b
      Shaun Pereira authored
      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
      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.
      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
      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: default avatarShaun Pereira <spereira@tusc.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Shaun Pereira's avatar
      [X25]: Selective sub-address matching with call user data. · cb65d506
      Shaun Pereira authored
      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 ( 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
      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 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: default avatarShaun Pereira <spereira@tusc.com.au>
      (With a fix from Alexey Dobriyan <adobriyan@gmail.com>)
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  15. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!