From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Masters Subject: Re: debug: nt_conntrack and KVM crash Date: Mon, 01 Feb 2010 05:38:15 -0500 Message-ID: <1265020695.7499.151.camel@tonnant> References: <1264813832.2793.446.camel@tonnant> <1264816634.2793.505.camel@tonnant> <1264816777.2793.510.camel@tonnant> <1264834704.2919.3.camel@edumazet-laptop> <1265016745.7499.144.camel@tonnant> <1265019160.2848.14.camel@edumazet-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Eric Dumazet , linux-kernel , netdev , netfilter-devel , Patrick McHardy To: Alexey Dobriyan Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netfilter-devel.vger.kernel.org On Mon, 2010-02-01 at 12:25 +0200, Alexey Dobriyan wrote: > On Mon, Feb 1, 2010 at 12:12 PM, Eric Dumazet wrote: > > Le lundi 01 f=C3=A9vrier 2010 =C3=A0 11:36 +0200, Alexey Dobriyan a= =C3=A9crit : > >> On Mon, Feb 1, 2010 at 11:32 AM, Jon Masters wrote: > >> > I hacked up a per-namespace version of hashtables (this needs do= ing > >> > 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. >=20 > It's not "complete", because right now there is no point in doing mor= e. > nf_conntrack_max was rejected given the absense of per-netns kernel > memory consumption limiting. >=20 > > 1) Global settings (shared by all netns) >=20 > 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.