1. 15 8月, 2012 1 次提交
  2. 01 11月, 2011 1 次提交
  3. 27 12月, 2009 3 次提交
    • O
      llc: convert llc_sap_list to RCU · 8beb9ab6
      Octavian Purdila 提交于
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8beb9ab6
    • O
      llc: replace the socket list with a local address based hash · 52d58aef
      Octavian Purdila 提交于
      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: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52d58aef
    • O
      llc: convert the socket list to RCU locking · b76f5a84
      Octavian Purdila 提交于
      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
      once.
      
      Note that the /proc and multicast delivery was not yet converted to
      RCU, it still uses spinlocks for protection.
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b76f5a84
  4. 06 8月, 2009 1 次提交
  5. 18 6月, 2009 1 次提交
  6. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      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
      protection.
      
      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: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  7. 28 10月, 2008 1 次提交
  8. 29 2月, 2008 1 次提交
  9. 11 10月, 2007 2 次提交
  10. 11 7月, 2007 1 次提交
  11. 13 2月, 2007 1 次提交
  12. 11 2月, 2007 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 22 9月, 2005 1 次提交
  15. 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