From: Andrew Vagin <avagin@parallels.com>
To: Florian Westphal <fw@strlen.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Andrey Vagin <avagin@openvz.org>,
netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, vvs@openvz.org,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
"David S. Miller" <davem@davemloft.net>,
Cyrill Gorcunov <gorcunov@openvz.org>
Subject: Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
Date: Fri, 10 Jan 2014 01:07:49 +0400 [thread overview]
Message-ID: <20140109210749.GA29440@paralelels.com> (raw)
In-Reply-To: <20140109205622.GA29458@breakpoint.cc>
On Thu, Jan 09, 2014 at 09:56:22PM +0100, Florian Westphal wrote:
> Andrew Vagin <avagin@parallels.com> wrote:
> > Can we allocate conntrack with zero ct_general.use and increment it at
> > the first time before inserting the conntrack into the hash table?
> > When conntrack is allocated it is attached exclusively to one skb.
> > It must be destroyed with skb, if it has not been confirmed, so we
> > don't need refcnt on this stage.
> >
> > I found only one place, where a reference counter of unconfirmed
> > conntract can incremented. It's ctnetlink_dump_table().
>
> What about skb_clone, etc? They will also increment the refcnt
> if a conntrack entry is attached to the skb.
We can not attach an unconfirmed conntrack to a few skb, because
nf_nat_setup_info can be executed concurrently for the same conntrack.
How do we avoid this race condition for cloned skb-s?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Vagin <avagin@parallels.com>
To: Florian Westphal <fw@strlen.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Andrey Vagin <avagin@openvz.org>,
<netfilter-devel@vger.kernel.org>, <netfilter@vger.kernel.org>,
<coreteam@netfilter.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <vvs@openvz.org>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
"David S. Miller" <davem@davemloft.net>,
"Cyrill Gorcunov" <gorcunov@openvz.org>
Subject: Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
Date: Fri, 10 Jan 2014 01:07:49 +0400 [thread overview]
Message-ID: <20140109210749.GA29440@paralelels.com> (raw)
In-Reply-To: <20140109205622.GA29458@breakpoint.cc>
On Thu, Jan 09, 2014 at 09:56:22PM +0100, Florian Westphal wrote:
> Andrew Vagin <avagin@parallels.com> wrote:
> > Can we allocate conntrack with zero ct_general.use and increment it at
> > the first time before inserting the conntrack into the hash table?
> > When conntrack is allocated it is attached exclusively to one skb.
> > It must be destroyed with skb, if it has not been confirmed, so we
> > don't need refcnt on this stage.
> >
> > I found only one place, where a reference counter of unconfirmed
> > conntract can incremented. It's ctnetlink_dump_table().
>
> What about skb_clone, etc? They will also increment the refcnt
> if a conntrack entry is attached to the skb.
We can not attach an unconfirmed conntrack to a few skb, because
nf_nat_setup_info can be executed concurrently for the same conntrack.
How do we avoid this race condition for cloned skb-s?
next prev parent reply other threads:[~2014-01-09 21:07 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 [this message]
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
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=20140109210749.GA29440@paralelels.com \
--to=avagin@parallels.com \
--cc=avagin@openvz.org \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=gorcunov@openvz.org \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=vvs@openvz.org \
/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.