[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140106172130.GA2360@moon>
Date: Mon, 6 Jan 2014 21:21:30 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Andrey Vagin <avagin@...nvz.org>, netfilter-devel@...r.kernel.org,
netfilter@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
vvs@...nvz.org, Pablo Neira Ayuso <pablo@...filter.org>,
Patrick McHardy <kaber@...sh.net>,
Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] netfilter: nf_conntrack: release conntrack from rcu
callback
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists