aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ps3_gelic_net.c
diff options
context:
space:
mode:
authorEric Dumazet <eric.dumazet@gmail.com>2009-07-23 16:15:34 +0200
committerGreg Kroah-Hartman <gregkh@suse.de>2009-07-30 14:40:29 -0700
commitf95d9271ff0e58fb12fc6f90c13f70d41eee8089 (patch)
tree2609e36c98ca6c2dc0a740d1cdcf54af17f3c5e5 /drivers/net/ps3_gelic_net.c
parent7500f93f415a2fc07e0031d99fa3964bf8981cfc (diff)
nf_conntrack: nf_conntrack_alloc() fixes
commit 941297f443f871b8c3372feccf27a8733f6ce9e9 upstream. When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating objects, since slab allocator could give a freed object still used by lockless readers. In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next being always valid (ie containing a valid 'nulls' value, or a valid pointer to next object in hash chain.) kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid for ct->tuplehash[xxx].hnnode.next. Fix is to call kmem_cache_alloc() and do the zeroing ourself. As spotted by Patrick, we also need to make sure lookup keys are committed to memory before setting refcount to 1, or a lockless reader could get a reference on the old version of the object. Its key re-check could then pass the barrier. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/net/ps3_gelic_net.c')
0 files changed, 0 insertions, 0 deletions