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

[Patrick McHardy <kaber@trash.net>]

On Thu, Apr 11, 2013 at 11:34:52AM +0200, Florian Westphal wrote:
> 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.

We only set the IPS_SRC_NAT/IPS_DST_NAT flags for non-null bindings.
Checking for these should work.