[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1265020695.7499.151.camel@tonnant>
Date: Mon, 01 Feb 2010 05:38:15 -0500
From: Jon Masters <jonathan@...masters.org>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
netfilter-devel <netfilter-devel@...r.kernel.org>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: debug: nt_conntrack and KVM crash
On Mon, 2010-02-01 at 12:25 +0200, Alexey Dobriyan wrote:
> On Mon, Feb 1, 2010 at 12:12 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > Le lundi 01 février 2010 à 11:36 +0200, Alexey Dobriyan a écrit :
> >> On Mon, Feb 1, 2010 at 11:32 AM, Jon Masters <jonathan@...masters.org> wrote:
> >> > I hacked up a per-namespace version of hashtables (this needs doing
> >> > anyway, since the global stuff is just waiting to break)
> >>
> >> Which ones? Conntrack hashtables are per-netns.
> >
> > It seems they are, but this is not a complete work :
That's my point.
> They are per-netns.
>
> It's not "complete", because right now there is no point in doing more.
> nf_conntrack_max was rejected given the absense of per-netns kernel
> memory consumption limiting.
>
> > 1) Global settings (shared by all netns)
>
> Only hashtable size which is module parameter and
> there is no generic way to limit kernel memory (like beancounters).
And can be changed at any time you like (also an exported symbol) such
that existing hashtable indexing will fail and corrupt memory. There is
clearly a need for each of these hashtables to have its own metadata.
Jon.
--
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