From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@gnumonks.org>,
netfilter-devel <netfilter-devel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
yongjun_wei@trendmicro.com.cn, kaber@trash.net
Subject: Re: Oops with latest (netfilter) nf-next tree, when unloading iptable_nat
Date: Wed, 19 Sep 2012 21:14:52 +0200 [thread overview]
Message-ID: <1348082092.2761.142.camel@localhost> (raw)
In-Reply-To: <20120912213627.GJ14750@breakpoint.cc>
On Wed, 2012-09-12 at 23:36 +0200, Florian Westphal wrote:
[...cut...]
> On module removal nf_nat_ipv4 calls nf_iterate_cleanup which invokes
> nf_nat_proto_clean() for each conntrack. That will then call
> hlist_del_rcu(&nat->bysource) using eachs conntracks nat ext area.
>
> Problem is that nf_nat_proto_clean() is called multiple times for the same
> conntrack:
> a) nf_ct_iterate_cleanup() returns each ct twice (origin, reply)
> b) we call it both for l3 and for l4 protocol ids
>
> We barf in hlist_del_rcu the 2nd time because ->pprev is poisoned.
>
> This was introduced with the ipv6 nat patches.
>
> --- a/net/netfilter/nf_nat_core.c
> +++ b/net/netfilter/nf_nat_core.c
> @@ -487,7 +487,7 @@ static int nf_nat_proto_clean(struct nf_conn *i, void *data)
>
> if (clean->hash) {
> spin_lock_bh(&nf_nat_lock);
> - hlist_del_rcu(&nat->bysource);
> + hlist_del_init_rcu(&nat->bysource);
> spin_unlock_bh(&nf_nat_lock);
> } else {
>
> Would probably avoid it. I guess it would be nicer to only call this
> once for each ct.
Florian's patch fixes the Oops :-)
prev parent reply other threads:[~2012-09-19 19:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 9:51 Oops with latest (netfilter) nf-next tree, when unloading iptable_nat Jesper Dangaard Brouer
2012-09-12 21:36 ` Florian Westphal
2012-09-14 12:07 ` Pablo Neira Ayuso
2012-09-14 13:15 ` Patrick McHardy
2012-09-19 12:46 ` Jesper Dangaard Brouer
2012-09-20 6:57 ` Patrick McHardy
2012-09-20 7:29 ` Jesper Dangaard Brouer
2012-09-20 7:31 ` Patrick McHardy
2012-09-20 10:08 ` Pablo Neira Ayuso
2012-09-20 10:31 ` Patrick McHardy
2012-09-20 17:06 ` Patrick McHardy
2012-09-21 1:00 ` Pablo Neira Ayuso
2012-09-21 9:47 ` Jesper Dangaard Brouer
2012-09-21 10:03 ` Pablo Neira Ayuso
2012-09-21 10:17 ` Pablo Neira Ayuso
2012-09-19 19:14 ` Jesper Dangaard Brouer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1348082092.2761.142.camel@localhost \
--to=brouer@redhat.com \
--cc=fw@strlen.de \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@gnumonks.org \
--cc=yongjun_wei@trendmicro.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.