On Mon, Jan 06, 2014 at 06:02:35PM +0100, Florian Westphal wrote:
>
> Can you elaborate?
> Yes, nf_ct_is_dying(ct) might be called for the wrong conntrack.
>
> But, in case we _think_ that its the right one we call
> nf_ct_tuple_equal() to verify we indeed found the right one:
>
> h = ____nf_conntrack_find(net, zone, tuple, hash);
> if (h) { // might be released right now, but page won't go away (SLAB_BY_RCU)
> ct = nf_ct_tuplehash_to_ctrack(h);
> if (unlikely(nf_ct_is_dying(ct) ||
> !atomic_inc_not_zero(&ct->ct_general.use)))
> // which means we should hit this path (0 ref).
> h = NULL;
> else {
> // otherwise, it cannot go away from under us, since
> // we own a reference now.
> if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple) ||
> nf_ct_zone(ct) != zone)) {
> // if we get here, the entry got recycled on other cpu
> // for a different tuple, we can bail out and drop
> // the reference safely and re-try the lookup
> nf_ct_put(ct);
> goto begin;
> }
> }
I think tuple may match if
task 1 task 2 task 3
nf_conntrack_find_get
____nf_conntrack_find
destroy_conntrack
hlist_nulls_del_rcu
nf_conntrack_free
kmem_cache_free
__nf_conntrack_alloc
kmem_cache_alloc
if (nf_ct_is_dying(ct))
data is not yet cleaned
memset(&ct->tuplehash[IP_CT_DIR_MAX],
No? Or there something obvious I'm missing?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
