On Thu, Apr 11, 2013 at 11:34:52AM +0200, Florian Westphal wrote: > Patrick McHardy <kaber@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
