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. -- 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
