1. 10 1月, 2006 1 次提交
  2. 04 1月, 2006 1 次提交
    • 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
  3. 23 11月, 2005 1 次提交
  4. 10 11月, 2005 2 次提交
  5. 28 10月, 2005 1 次提交
  6. 26 10月, 2005 1 次提交
  7. 09 10月, 2005 1 次提交
  8. 07 9月, 2005 1 次提交
  9. 30 8月, 2005 9 次提交
  10. 19 7月, 2005 1 次提交
  11. 09 7月, 2005 1 次提交
  12. 27 6月, 2005 1 次提交
    • D
      [NETLINK]: Fix two socket hashing bugs. · d470e3b4
      David S. Miller 提交于
      1) netlink_release() should only decrement the hash entry
         count if the socket was actually hashed.
      
         This was causing hash->entries to underflow, which
         resulting in all kinds of troubles.
      
         On 64-bit systems, this would cause the following
         conditional to erroneously trigger:
      
      	err = -ENOMEM;
      	if (BITS_PER_LONG > 32 && unlikely(hash->entries >= UINT_MAX))
      		goto err;
      
      2) netlink_autobind() needs to propagate the error return from
         netlink_insert().  Otherwise, callers will not see the error
         as they should and thus try to operate on a socket with a zero pid,
         which is very bad.
      
         However, it should not propagate -EBUSY.  If two threads race
         to autobind the socket, that is fine.  This is consistent with the
         autobind behavior in other protocols.
      
         So bug #1 above, combined with this one, resulted in hangs
         on netlink_sendmsg() calls to the rtnetlink socket.  We'd try
         to do the user sendmsg() with the socket's pid set to zero,
         later we do a socket lookup using that pid (via the value we
         stashed away in NETLINK_CB(skb).pid), but that won't give us the
         user socket, it will give us the rtnetlink socket.  So when we
         try to wake up the receive queue, we dive back into rtnetlink_rcv()
         which tries to recursively take the rtnetlink semaphore.
      
      Thanks to Jakub Jelink for providing backtraces.  Also, thanks to
      Herbert Xu for supplying debugging patches to help track this down,
      and also finding a mistake in an earlier version of this fix.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d470e3b4
  13. 19 6月, 2005 1 次提交
  14. 20 5月, 2005 3 次提交
  15. 04 5月, 2005 1 次提交
    • H
      [NETLINK]: cb_lock does not needs ref count on sk · 96c36023
      Herbert Xu 提交于
      Here is a little optimisation for the cb_lock used by netlink_dump.
      While fixing that race earlier, I noticed that the reference count
      held by cb_lock is completely useless.  The reason is that in order
      to obtain the protection of the reference count, you have to take
      the cb_lock.  But the only way to take the cb_lock is through
      dereferencing the socket.
      
      That is, you must already possess a reference count on the socket
      before you can take advantage of the reference count held by cb_lock.
      As a corollary, we can remve the reference count held by the cb_lock.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96c36023
  16. 30 4月, 2005 1 次提交
  17. 29 4月, 2005 1 次提交
  18. 26 4月, 2005 2 次提交
    • A
      [NET]: kill gratitious includes of major.h · 5523662c
      Al Viro 提交于
      	A lot of places in there are including major.h for no reason
      whatsoever.  Removed.  And yes, it still builds.
      
      	The history of that stuff is often amusing.  E.g. for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used to
      need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need had
      disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops)
      in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of net/* had moved
      a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed...
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5523662c
    • A
      [PATCH] kill gratitious includes of major.h under net/* · b453257f
      Al Viro 提交于
      A lot of places in there are including major.h for no reason whatsoever.
      Removed.  And yes, it still builds. 
      
      The history of that stuff is often amusing.  E.g.  for net/core/sock.c
      the story looks so, as far as I've been able to reconstruct it: we used
      to need major.h in net/socket.c circa 1.1.early.  In 1.1.13 that need
      had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
      &net_fops) in sock_init().  Include had not.  When 1.2 -> 1.3 reorg of
      net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
      this crap had followed... 
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b453257f
  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