1. 14 Apr, 2016 1 commit
  2. 15 Aug, 2013 1 commit
  3. 15 Aug, 2012 1 commit
  4. 31 Oct, 2011 1 commit
  5. 27 Dec, 2009 3 commits
    • Octavian Purdila's avatar
    • Octavian Purdila's avatar
      llc: replace the socket list with a local address based hash · 52d58aef
      Octavian Purdila authored
      For the cases where a lot of interfaces are used in conjunction with a
      lot of LLC sockets bound to the same SAP, the iteration of the socket
      list becomes prohibitively expensive.
      Replacing the list with a a local address based hash significantly
      improves the bind and listener lookup operations as well as the
      datagram delivery.
      Connected sockets delivery is also improved, but this patch does not
      address the case where we have lots of sockets with the same local
      address connected to different remote addresses.
      In order to keep the socket sanity checks alive and fast a socket
      counter was added to the SAP structure.
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Octavian Purdila's avatar
      llc: convert the socket list to RCU locking · b76f5a84
      Octavian Purdila authored
      For the reclamation phase we use the SLAB_DESTROY_BY_RCU mechanism,
      which require some extra checks in the lookup code:
      a) If the current socket was released, reallocated & inserted in
      another list it will short circuit the iteration for the current list,
      thus we need to restart the lookup.
      b) If the current socket was released, reallocated & inserted in the
      same list we just need to recheck it matches the look-up criteria and
      if not we can skip to the next element.
      In this case there is no need to restart the lookup, since sockets are
      inserted at the start of the list and the worst that will happen is
      that we will iterate throught some of the list elements more then
      Note that the /proc and multicast delivery was not yet converted to
      RCU, it still uses spinlocks for protection.
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 05 Aug, 2009 1 commit
  7. 18 Jun, 2009 1 commit
  8. 30 Mar, 2009 1 commit
    • Alexey Dobriyan's avatar
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan authored
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      ->read_proc/->write_proc were just fixed to not require ->owner for
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      Removing ->owner will also make PDE smaller.
      So, let's nuke it.
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
  9. 28 Oct, 2008 1 commit
  10. 28 Feb, 2008 1 commit
  11. 10 Oct, 2007 2 commits
  12. 11 Jul, 2007 1 commit
  13. 12 Feb, 2007 1 commit
  14. 11 Feb, 2007 1 commit
  15. 30 Jun, 2006 1 commit
  16. 22 Sep, 2005 1 commit
  17. 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!