diff options
author | Eric Dumazet <eric.dumazet@gmail.com> | 2009-07-16 14:03:40 +0200 |
---|---|---|
committer | Patrick McHardy <kaber@trash.net> | 2009-07-16 14:03:40 +0200 |
commit | 941297f443f871b8c3372feccf27a8733f6ce9e9 (patch) | |
tree | c98b7e30bf14255cfd87a3d8d929f26f35764d21 /MAINTAINERS | |
parent | aa6a03eb0ae859c1371555ef381de4c96ca1e4e6 (diff) | |
download | linux-stable-941297f443f871b8c3372feccf27a8733f6ce9e9.tar.gz linux-stable-941297f443f871b8c3372feccf27a8733f6ce9e9.tar.bz2 linux-stable-941297f443f871b8c3372feccf27a8733f6ce9e9.zip |
netfilter: nf_conntrack: nf_conntrack_alloc() fixes
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>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions