[PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

STALE5513d

4 messages, 3 authors, 2011-09-14 · open the first message on its own page

[PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

From: Tim Gardner <hidden>
Date: 2011-09-12 18:03:25

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.

rtg
-- 
Tim Gardner tim.gardner@canonical.com

Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

From: Tim Gardner <hidden>
Date: 2011-09-12 18:43:06

On 09/12/2011 12:03 PM, 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.

rtg
Never mind. Looks like Alex already sent this patch on Sept 10 with the subject 'Fix repeatable Oops on container destroy with conntrack'.

rtg

-- 
Tim Gardner tim.gardner@canonical.com

Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

From: Julian Anastasov <ja@ssi.bg>
Date: 2011-09-12 20:40:41

	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 [off-list ref]

Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: 2011-09-14 12:31:44

On Mon, Sep 12, 2011 at 12:03:13PM -0600, 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're still discussing a better solution for it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help