android_kernel_xiaomi_sm8350/Documentation/RCU
Eric Dumazet 941297f443 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>
2009-07-16 14:03:40 +02:00
..
00-INDEX
arrayRCU.txt
checklist.txt
listRCU.txt Doc: Fix wrong API example usage of call_rcu(). 2009-04-02 01:33:50 -07:00
NMI-RCU.txt
rcu.txt
rcubarrier.txt
rculist_nulls.txt netfilter: nf_conntrack: nf_conntrack_alloc() fixes 2009-07-16 14:03:40 +02:00
rcuref.txt
RTFP.txt
torture.txt
trace.txt rcu: Update RCU tracing documentation for __rcu_pending 2009-04-14 11:33:43 +02:00
UP.txt
whatisRCU.txt