Re: Fwd: Re: [BUG] Fatal exception in interrupt - nf_nat_cleanup_conntrack during IPv6 tests

[Florian Westphal <fw@strlen.de>]

Patrick McHardy <kaber@trash.net> wrote:
> > > > Looks like it, nf_nat_ipv4 is listed as F- in the oops trace. (afaics,
> > > > "-" means "module going away").
> > > 
> > > Yes, that seems like a real race condition. We probably could extend the
> > > nf_nat_lock sections to avoid this, but I wonder wether we should just kill
> > > those conntracks, the connections are not going to work after being
> > > "de-nated" anymore anyway.
> > 
> > I like it, just killing them would make it a lot more simple.
> > 
> > The clear-nat-extension-on-module-unload dance is getting out of hand,
> > and, as you point out, the connections are not going to work anyway...
> 
> Yeah, lets just do that. Do you want to take care of this?

I can look into it, sure.
However, i missed one important point: non-NAT'd connections
have a null binding, and there doesn't seem to be a way to differentiate
between real vs. null binding.

Simply returning 1 for conntracks-with-nat-extension will zap every
connection.