Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752214Ab0BBKsL (ORCPT ); Tue, 2 Feb 2010 05:48:11 -0500 Received: from dallas.jonmasters.org ([72.29.103.172]:42676 "EHLO dallas.jonmasters.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736Ab0BBKsJ (ORCPT ); Tue, 2 Feb 2010 05:48:09 -0500 Subject: Re: [PATCH] netfilter: per netns nf_conntrack_cachep From: Jon Masters To: Eric Dumazet Cc: Alexey Dobriyan , Patrick McHardy , linux-kernel , netdev , netfilter-devel , "Paul E. McKenney" In-Reply-To: <1265035970.2848.50.camel@edumazet-laptop> 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> <1265023437.2848.30.camel@edumazet-laptop> <1265035970.2848.50.camel@edumazet-laptop> Content-Type: text/plain Organization: World Organi[sz]ation of Broken Dreams Date: Tue, 02 Feb 2010 05:47:45 -0500 Message-Id: <1265107666.2861.117.camel@tonnant> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: jonathan@jonmasters.org X-SA-Exim-Scanned: No (on dallas.jonmasters.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 31 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/