Linux Netfilter development
 help / color / mirror / Atom feed
From: Jon Masters <jonathan@jonmasters.org>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: netfilter-devel <netfilter-devel@vger.kernel.org>,
	Patrick McHardy <kaber@trash.net>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Jason Wessel <jason.wessel@windriver.com>
Subject: SUMMARY: KVM+nf_conntrack_htable_size
Date: Sun, 31 Jan 2010 04:10:33 -0500	[thread overview]
Message-ID: <1264929033.7499.22.camel@tonnant> (raw)

Folks,

Thanks to everyone who helped me poke a little at the netfilter code.
Since I'm not usually a network guy and haven't really kept up with
things like the namespace code, this was fun. I have some results.

The problem (as Eric hinted) is that we have a global
nf_conntrack_htable_size, which is manipulated every time we create a
new hashtable. This used to happen only once, but now that we have
multiple network namespaces, it will happen every time we create a new
namespace due to the code registering with register_pernet_subsys. At
this time, the value of the hashtable may be changed underneath code
that is currently using it for another hashtable instance. Additionally,
the "resize" code (via module parameter or via sysctl) only changes the
root netns hashtable, then changes this value, also busticating stuff.
Finally, the very fact that this variable is exported directly is
*asking* for trouble and random corruption to happen later on.

So, there are a great many issues with how the conntrack hashtables are
managed (looks literally as it it used to be fine then namespace code
came along and broke assumptions that had been there since the start),
and they should not be considered safe for use with multiple namespaces
in my opinion. The solution would seem to be to remove this as a global
and make it per namespace, or even per hashtable (there is usually a 1:1
mapping, but the expect code uses this variable too).

Can someone give me some advice on which solution you prefer of these?
Or if you have an alternative preference. I think for now I'll hack up
something involving per-namespace hashtable sizes.

Jon.



                 reply	other threads:[~2010-01-31  9:10 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1264929033.7499.22.camel@tonnant \
    --to=jonathan@jonmasters.org \
    --cc=adobriyan@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=jason.wessel@windriver.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox