[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1109122256450.1592@ja.ssi.bg>
Date: Mon, 12 Sep 2011 23:40:42 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: Tim Gardner <tim.gardner@...onical.com>
cc: kaber@...sh.net, linux-kernel@...r.kernel.org,
David Miller <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, netfilter@...r.kernel.org,
coreteam@...filter.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event
to, avoid Oops on container destroy
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 <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists