1. 15 Apr, 2012 1 commit
  2. 21 Mar, 2012 1 commit
  3. 30 Dec, 2011 1 commit
  4. 16 Dec, 2011 1 commit
  5. 24 Apr, 2011 1 commit
  6. 29 Nov, 2010 1 commit
  7. 16 Jun, 2010 1 commit
  8. 01 May, 2010 1 commit
    • Eric Dumazet's avatar
      net: sock_def_readable() and friends RCU conversion · 43815482
      Eric Dumazet authored
      sk_callback_lock rwlock actually protects sk->sk_sleep pointer, so we
      need two atomic operations (and associated dirtying) per incoming
      RCU conversion is pretty much needed :
      1) Add a new structure, called "struct socket_wq" to hold all fields
      that will need rcu_read_lock() protection (currently: a
      wait_queue_head_t and a struct fasync_struct pointer).
      [Future patch will add a list anchor for wakeup coalescing]
      2) Attach one of such structure to each "struct socket" created in
      3) Respect RCU grace period when freeing a "struct socket_wq"
      4) Change sk_sleep pointer in "struct sock" by sk_wq, pointer to "struct
      5) Change sk_sleep() function to use new sk->sk_wq instead of
      6) Change sk_has_sleeper() to wq_has_sleeper() that must be used inside
      a rcu_read_lock() section.
      7) Change all sk_has_sleeper() callers to :
        - Use rcu_read_lock() instead of read_lock(&sk->sk_callback_lock)
        - Use wq_has_sleeper() to eventually wakeup tasks.
        - Use rcu_read_unlock() instead of read_unlock(&sk->sk_callback_lock)
      8) sock_wake_async() is modified to use rcu protection as well.
      9) Exceptions :
        macvtap, drivers/net/tun.c, af_unix use integrated "struct socket_wq"
      instead of dynamically allocated ones. They dont need rcu freeing.
      Some cleanups or followups are probably needed, (possible
      sk_callback_lock conversion to a spinlock for example...).
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 26 Nov, 2008 1 commit
  10. 09 Nov, 2008 1 commit
    • Miklos Szeredi's avatar
      net: unix: fix inflight counting bug in garbage collector · 6209344f
      Miklos Szeredi authored
      Previously I assumed that the receive queues of candidates don't
      change during the GC.  This is only half true, nothing can be received
      from the queues (see comment in unix_gc()), but buffers could be added
      through the other half of the socket pair, which may still have file
      descriptors referring to it.
      This can result in inc_inflight_move_tail() erronously increasing the
      "inflight" counter for a unix socket for which dec_inflight() wasn't
      previously called.  This in turn can trigger the "BUG_ON(total_refs <
      inflight_refs)" in a later garbage collection run.
      Fix this by only manipulating the "inflight" counter for sockets which
      are candidates themselves.  Duplicating the file references in
      unix_attach_fds() is also needed to prevent a socket becoming a
      candidate for GC while the skb that contains it is not yet queued.
      Reported-by: default avatarAndrea Bittau <a.bittau@cs.ucl.ac.uk>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      CC: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 27 Jul, 2008 1 commit
  12. 28 Jan, 2008 2 commits
  13. 11 Nov, 2007 1 commit
  14. 31 Jul, 2007 1 commit
  15. 11 Jul, 2007 1 commit
    • Miklos Szeredi's avatar
      [AF_UNIX]: Rewrite garbage collector, fixes race. · 1fd05ba5
      Miklos Szeredi authored
      Throw out the old mark & sweep garbage collector and put in a
      refcounting cycle detecting one.
      The old one had a race with recvmsg, that resulted in false positives
      and hence data loss.  The old algorithm operated on all unix sockets
      in the system, so any additional locking would have meant performance
      problems for all users of these.
      The new algorithm instead only operates on "in flight" sockets, which
      are very rare, and the additional locking for these doesn't negatively
      impact the vast majority of users.
      In fact it's probable, that there weren't *any* heavy senders of
      sockets over sockets, otherwise the above race would have been
      discovered long ago.
      The patch works OK with the app that exposed the race with the old
      code.  The garbage collection has also been verified to work in a few
      simple cases.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  16. 04 Jun, 2007 1 commit
  17. 02 Aug, 2006 1 commit
    • Catherine Zhang's avatar
      [AF_UNIX]: Kernel memory leak fix for af_unix datagram getpeersec patch · dc49c1f9
      Catherine Zhang authored
      From: Catherine Zhang <cxzhang@watson.ibm.com>
      This patch implements a cleaner fix for the memory leak problem of the
      original unix datagram getpeersec patch.  Instead of creating a
      security context each time a unix datagram is sent, we only create the
      security context when the receiver requests it.
      This new design requires modification of the current
      unix_getsecpeer_dgram LSM hook and addition of two new hooks, namely,
      secid_to_secctx and release_secctx.  The former retrieves the security
      context and the latter releases it.  A hook is required for releasing
      the security context because it is up to the security module to decide
      how that's done.  In the case of Selinux, it's a simple kfree
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  18. 03 Jul, 2006 1 commit
  19. 29 Jun, 2006 1 commit
    • Catherine Zhang's avatar
      [AF_UNIX]: Datagram getpeersec · 877ce7c1
      Catherine Zhang authored
      This patch implements an API whereby an application can determine the
      label of its peer's Unix datagram sockets via the auxiliary data mechanism of
      Patch purpose:
      This patch enables a security-aware application to retrieve the
      security context of the peer of a Unix datagram socket.  The application
      can then use this security context to determine the security context for
      processing on behalf of the peer who sent the packet.
      Patch design and implementation:
      The design and implementation is very similar to the UDP case for INET
      sockets.  Basically we build upon the existing Unix domain socket API for
      retrieving user credentials.  Linux offers the API for obtaining user
      credentials via ancillary messages (i.e., out of band/control messages
      that are bundled together with a normal message).  To retrieve the security
      context, the application first indicates to the kernel such desire by
      setting the SO_PASSSEC option via getsockopt.  Then the application
      retrieves the security context using the auxiliary data mechanism.
      An example server application for Unix datagram socket should look like this:
      toggle = 1;
      toggle_len = sizeof(toggle);
      setsockopt(sockfd, SOL_SOCKET, SO_PASSSEC, &toggle, &toggle_len);
      recvmsg(sockfd, &msg_hdr, 0);
      if (msg_hdr.msg_controllen > sizeof(struct cmsghdr)) {
          cmsg_hdr = CMSG_FIRSTHDR(&msg_hdr);
          if (cmsg_hdr->cmsg_len <= CMSG_LEN(sizeof(scontext)) &&
              cmsg_hdr->cmsg_level == SOL_SOCKET &&
              cmsg_hdr->cmsg_type == SCM_SECURITY) {
              memcpy(&scontext, CMSG_DATA(cmsg_hdr), sizeof(scontext));
      sock_setsockopt is enhanced with a new socket option SOCK_PASSSEC to allow
      a server socket to receive security context of the peer.
      We have tested the patch by setting up Unix datagram client and server
      applications.  We verified that the server can retrieve the security context
      using the auxiliary data mechanism of recvmsg.
      Signed-off-by: default avatarCatherine Zhang <cxzhang@watson.ibm.com>
      Acked-by: default avatarAcked-by: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  20. 26 Apr, 2006 1 commit
  21. 21 Mar, 2006 1 commit
  22. 03 Jan, 2006 2 commits
  23. 29 Aug, 2005 1 commit
  24. 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!