linux.git/include/net/sock.h, branch v2.6.29-rc2

net: Use a percpu_counter for orphan_count

2008-11-26T05:17:14+00:00

Instead of using one atomic_t per protocol, use a percpu_counter
for "orphan_count", to reduce cache line contention on
heavy duty network servers. 

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

net: Use a percpu_counter for sockets_allocated

2008-11-26T05:16:35+00:00

Instead of using one atomic_t per protocol, use a percpu_counter
for "sockets_allocated", to reduce cache line contention on
heavy duty network servers. 

Note : We revert commit (248969ae31e1b3276fc4399d67ce29a5d81e6fd9
net: af_unix can make unix_nr_socks visbile in /proc),
since it is not anymore used after sock_prot_inuse_add() addition

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2008-11-19T07:38:23+00:00

Conflicts:

	drivers/isdn/i4l/isdn_net.c
	fs/cifs/connect.c

udp: Use hlist_nulls in UDP RCU code

2008-11-17T03:39:21+00:00

This is a straightforward patch, using hlist_nulls infrastructure.

RCUification already done on UDP two weeks ago.

Using hlist_nulls permits us to avoid some memory barriers, both
at lookup time and delete time.

Patch is large because it adds new macros to include/net/sock.h.
These macros will be used by TCP & DCCP in next patch.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c

2008-11-14T07:19:10+00:00

fix this warning:

  net/bluetooth/af_bluetooth.c:60: warning: ‘bt_key_strings’ defined but not used
  net/bluetooth/af_bluetooth.c:71: warning: ‘bt_slock_key_strings’ defined but not used

this is a lockdep macro problem in the !LOCKDEP case.

We cannot convert it to an inline because the macro works on multiple types,
but we can mark the parameter used.

[ also clean up a misaligned tab in sock_lock_init_class_and_name() ]

[ also remove #ifdefs from around af_family_clock_key strings - which
  were certainly added to get rid of the ugly build warnings. ]

Signed-off-by: Ingo Molnar 
Signed-off-by: David S. Miller

net: ifdef struct sock::sk_async_wait_queue

2008-11-13T07:25:32+00:00

Every user is under CONFIG_NET_DMA already, so ifdef field as well.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller

net: #ifdef ->sk_security

2008-11-04T22:45:58+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2008-10-31T07:17:34+00:00

Conflicts:

	drivers/net/wireless/p54/p54common.c

net: delete excess kernel-doc notation

2008-10-31T06:54:35+00:00

Remove excess kernel-doc function parameters from networking header
& driver files:

Warning(include/net/sock.h:946): Excess function parameter or struct member 'sk' description in 'sk_filter_release'
Warning(include/linux/netdevice.h:1545): Excess function parameter or struct member 'cpu' description in 'netif_tx_lock'
Warning(drivers/net/wan/z85230.c:712): Excess function parameter or struct member 'regs' description in 'z8530_interrupt'

Signed-off-by: Randy Dunlap 
Signed-off-by: David S. Miller

udp: introduce sk_for_each_rcu_safenext()

2008-10-29T18:19:58+00:00

Corey Minyard found a race added in commit 271b72c7fa82c2c7a795bc16896149933110672d
(udp: RCU handling for Unicast packets.)

 "If the socket is moved from one list to another list in-between the
 time the hash is calculated and the next field is accessed, and the
 socket has moved to the end of the new list, the traversal will not
 complete properly on the list it should have, since the socket will
 be on the end of the new list and there's not a way to tell it's on a
 new list and restart the list traversal.  I think that this can be
 solved by pre-fetching the "next" field (with proper barriers) before
 checking the hash."

This patch corrects this problem, introducing a new
sk_for_each_rcu_safenext() macro.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller