From: Jon Masters <jonathan@jonmasters.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
Patrick McHardy <kaber@trash.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
netfilter-devel <netfilter-devel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] netfilter: per netns nf_conntrack_cachep
Date: Tue, 02 Feb 2010 05:47:45 -0500 [thread overview]
Message-ID: <1265107666.2861.117.camel@tonnant> (raw)
In-Reply-To: <1265035970.2848.50.camel@edumazet-laptop>
On Mon, 2010-02-01 at 15:52 +0100, Eric Dumazet wrote:
> [PATCH] netfilter: per netns nf_conntrack_cachep
>
> nf_conntrack_cachep is currently shared by all netns instances, but
> because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.
>
> If we use a shared slab cache, one object can instantly flight between
> one hash table (netns ONE) to another one (netns TWO), and concurrent
> reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
> can be fooled without notice, because no RCU grace period has to be
> observed between object freeing and its reuse.
I'll test this patch.
After some lengthy debugging, what actually happens here is that the
nf_conntrack_cachep SL*U*B gets corrupted such that the contained
per-cpu cpu_slabs are all pointing to the address of htable_size, which
is then helpfully set to be the value of the individual freelists (the
address of the base of the kmem_cache), or offset '51' into the table.
The worrying thing is it looks like this is actually corrupting other
random memory too, it just happens to bite once we get this far.
Jon.
next prev parent reply other threads:[~2010-02-02 10:47 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 1:10 debug: nt_conntrack and KVM crash Jon Masters
2010-01-30 1:57 ` Jon Masters
2010-01-30 1:59 ` Jon Masters
2010-01-30 6:58 ` Eric Dumazet
2010-01-30 7:36 ` Jon Masters
2010-01-30 7:40 ` Jon Masters
2010-01-30 8:33 ` Eric Dumazet
2010-01-30 10:03 ` Jon Masters
2010-02-01 9:32 ` Jon Masters
2010-02-01 9:36 ` Alexey Dobriyan
2010-02-01 10:12 ` Eric Dumazet
2010-02-01 10:25 ` Alexey Dobriyan
2010-02-01 10:38 ` Jon Masters
2010-02-01 11:23 ` Eric Dumazet
2010-02-01 14:48 ` Alexey Dobriyan
2010-02-01 14:57 ` Eric Dumazet
2010-02-01 14:52 ` [PATCH] netfilter: per netns nf_conntrack_cachep Eric Dumazet
2010-02-01 14:58 ` Alexey Dobriyan
2010-02-01 15:02 ` Eric Dumazet
2010-02-02 11:04 ` Jon Masters
2010-02-02 11:35 ` Jon Masters
2010-02-02 16:46 ` Jon Masters
2010-02-02 16:48 ` Patrick McHardy
2010-02-02 17:07 ` Jon Masters
2010-02-02 17:58 ` Alexey Dobriyan
2010-02-02 18:16 ` Jon Masters
2010-02-02 18:34 ` Jon Masters
2010-02-02 18:36 ` Patrick McHardy
2010-02-02 18:39 ` Jon Masters
2010-02-02 18:42 ` Jon Masters
2010-02-03 12:10 ` Patrick McHardy
2010-02-03 18:38 ` Jon Masters
2010-02-03 19:09 ` Alexey Dobriyan
2010-02-03 19:43 ` Jon Masters
2010-02-03 19:46 ` Jon Masters
2010-02-03 19:53 ` Alexey Dobriyan
2010-02-03 20:04 ` Jon Masters
2010-02-03 19:51 ` Alexey Dobriyan
2010-02-03 19:53 ` Jon Masters
2010-02-03 20:01 ` Alexey Dobriyan
2010-02-04 12:25 ` Patrick McHardy
2010-02-04 12:27 ` Alexey Dobriyan
2010-02-04 12:30 ` Patrick McHardy
2010-02-04 12:35 ` Alexey Dobriyan
2010-02-04 13:04 ` Patrick McHardy
2010-02-04 13:18 ` Jon Masters
2010-02-04 13:37 ` Patrick McHardy
2010-02-04 13:42 ` Jon Masters
2010-02-03 20:21 ` Jon Masters
2010-02-04 12:24 ` Patrick McHardy
2010-02-02 16:58 ` PROBLEM with summary: " Jon Masters
2010-02-02 17:04 ` Patrick McHardy
2010-02-02 17:16 ` Eric Dumazet
2010-02-02 17:23 ` Jon Masters
2010-02-02 4:36 ` Jon Masters
2010-02-02 7:02 ` Jon Masters
2010-02-02 10:47 ` Jon Masters [this message]
2010-02-04 14:00 ` Patrick McHardy
2010-02-01 10:35 ` debug: nt_conntrack and KVM crash Jon Masters
2010-02-01 10:44 ` Alexey Dobriyan
2010-02-01 10:47 ` Alexey Dobriyan
2010-02-01 10:49 ` Alexey Dobriyan
2010-02-01 10:53 ` Jon Masters
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=1265107666.2861.117.camel@tonnant \
--to=jonathan@jonmasters.org \
--cc=adobriyan@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).