From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754710Ab1ILUkl (ORCPT ); Mon, 12 Sep 2011 16:40:41 -0400 Received: from ja.ssi.bg ([178.16.129.10]:56339 "EHLO ja.ssi.bg" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752699Ab1ILUkk (ORCPT ); Mon, 12 Sep 2011 16:40:40 -0400 Date: Mon, 12 Sep 2011 23:40:42 +0300 (EEST) From: Julian Anastasov To: Tim Gardner cc: kaber@trash.net, linux-kernel@vger.kernel.org, David Miller , netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org Subject: Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy In-Reply-To: <4E6E4961.9070802@canonical.com> Message-ID: References: <4E6E4961.9070802@canonical.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Mon, 12 Sep 2011, Tim Gardner wrote: > Patrick, > > I received this patch from a developer that uses lxc and network name spaces. > I don't know the locking semantics well enough for CT to judge whether this > fix is sufficient. Bug info can be found at > http://bugs.launchpad.net/bugs/843892 . See comment #7 for his analysis. We found same problems triggered by IPVS during subsys cleanup: http://marc.info/?l=netfilter-devel&m=130765388528399&w=2 It is a general problem for modules that register callbacks to the netfilter core. nfnetlink is such example with a mix of global (ctnl_notifier) and per-net (nfnetlink_net_ops) registrations. During net cleanup the module must be prepared to be called by core because the core cleanup happens later. So, may be rcu_dereference under rcu lock is needed for some functions (nfnetlink_has_listeners, nfnetlink_send) but such changes should be audited by nfnetlink developers. Using rcu_assign_pointer for net->nfnl without corresponding rcu_dereference looks like a problem. Regards -- Julian Anastasov