From: Florian Westphal <fw@strlen.de>
To: Andrey Vagin <avagin@openvz.org>
Cc: netfilter-devel@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>,
netfilter@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, vvs@openvz.org,
Florian Westphal <fw@strlen.de>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Vasiliy Averin <vvs@parallels.com>
Subject: Re: [PATCH] [RFC] netfilter: nf_conntrack: don't relase a conntrack with non-zero refcnt
Date: Tue, 14 Jan 2014 19:53:29 +0100 [thread overview]
Message-ID: <20140114185329.GB28205@breakpoint.cc> (raw)
In-Reply-To: <1389720948-7883-1-git-send-email-avagin@openvz.org>
Andrey Vagin <avagin@openvz.org> wrote:
> ----
> Eric and Florian, could you look at this patch. When you say,
> that it looks good, I will ask the user to validate it.
> I can't reorder these actions, because it's reproduced on a real host
> with real users. Thanks.
> ----
>
> nf_conntrack_free can't be called for a conntract with non-zero ref-counter,
> because it can race with nf_conntrack_find_get().
Indeed.
> A conntrack slab is created with SLAB_DESTROY_BY_RCU. Non-zero
> ref-conunter says that this conntrack is used now. So when we release a
> conntrack with non-zero counter, we break this assumption.
>
> CPU1 CPU2
> ____nf_conntrack_find()
> nf_ct_put()
> destroy_conntrack()
> ...
> init_conntrack
> __nf_conntrack_alloc (set use = 1)
> atomic_inc_not_zero(&ct->use) (use = 2)
> if (!l4proto->new(ct, skb, dataoff, timeouts))
> nf_conntrack_free(ct); (use = 2 !!!)
> ...
Yes, I think this sequence is possible; we must not use nf_conntrack_free here.
> - /* We overload first tuple to link into unconfirmed or dying list.*/
> - BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
> - hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
> + if (!hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode))
> + hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
This is the only thing that I don't like about this patch. Currently
all the conntracks in the system are always put on a list before they're
supposed to be visible/handled via refcnt system (unconfirmed, hash, or
dying list).
I think it would be nice if we could keep it that way.
If everything fails we could proably intoduce a 'larval' dummy list
similar to the one used by template conntracks?
next prev parent reply other threads:[~2014-01-14 18:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-07 10:31 [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get Andrey Vagin
2014-01-07 11:42 ` Vasily Averin
2014-01-07 15:08 ` Eric Dumazet
2014-01-07 15:25 ` Florian Westphal
2014-01-08 13:42 ` Eric Dumazet
2014-01-08 14:04 ` Florian Westphal
2014-01-08 17:31 ` Eric Dumazet
2014-01-08 20:18 ` Florian Westphal
2014-01-08 20:23 ` Florian Westphal
2014-01-09 20:32 ` Andrew Vagin
2014-01-09 20:32 ` Andrew Vagin
2014-01-09 20:56 ` Florian Westphal
2014-01-09 21:07 ` Andrew Vagin
2014-01-09 21:07 ` Andrew Vagin
2014-01-09 21:26 ` Florian Westphal
2014-01-09 5:24 ` Andrew Vagin
2014-01-09 15:23 ` Eric Dumazet
2014-01-09 21:46 ` Andrey Wagin
2014-01-08 13:17 ` [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v2) Andrey Vagin
2014-01-08 13:47 ` Eric Dumazet
2014-01-12 17:50 ` [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v3) Andrey Vagin
2014-01-12 20:21 ` Eric Dumazet
2014-01-14 10:51 ` Andrew Vagin
2014-01-14 10:51 ` Andrew Vagin
2014-01-14 10:51 ` Andrew Vagin
2014-01-14 11:10 ` Andrey Wagin
2014-01-14 14:36 ` Eric Dumazet
2014-01-14 17:35 ` [PATCH] [RFC] netfilter: nf_conntrack: don't relase a conntrack with non-zero refcnt Andrey Vagin
2014-01-14 17:44 ` Cyrill Gorcunov
2014-01-14 18:53 ` Florian Westphal [this message]
2014-01-15 18:08 ` Andrew Vagin
2014-01-15 18:08 ` Andrew Vagin
2014-01-16 9:23 ` Florian Westphal
2014-02-02 23:30 ` Pablo Neira Ayuso
2014-02-03 13:59 ` Andrew Vagin
2014-02-03 13:59 ` Andrew Vagin
2014-02-03 16:22 ` Eric Dumazet
2014-01-27 13:44 ` Andrew Vagin
2014-01-27 13:44 ` Andrew Vagin
2014-01-29 19:21 ` [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get (v3) Pablo Neira Ayuso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140114185329.GB28205@breakpoint.cc \
--to=fw@strlen.de \
--cc=avagin@openvz.org \
--cc=eric.dumazet@gmail.com \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=vvs@openvz.org \
--cc=vvs@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.