On Thu, Sep 18, 2014 at 04:31:08PM +0200, Florian Westphal wrote: > > I also guess most distributors will use CONFIG_BRIDGE_NETFILTER=m. > > Then, users will get a warning message to let them know that they will > > have to modprobe br_netfilter in the future if they need it, so we can > > remove the deferred request_module from the br init path. > > Hmm, not sure if its safe to do this, e.g. with bridge=y, > br_netfilter=m, module might not yet be present in such cases? > > Also, what about this: > iptables-restore < rules.txt > modprobe bridge > brctl addbr ... > brctl addif ... > > at this point, any packet forwarded by bridge is filtered > via iptables. > > After your patch, this might no longer be the case, if the modprobe > call is delayed (maybe this is far-fetched and not an issue in practice)? Agreed, I think we can use your static key approach to drop traffic from br_handle_frame after the work has called request_module. > 2nd hypothetical issue: > modprobe bridge > sysctl net.bridge.bridge-nf-call-iptables=0 > > The sysctl could fail when br_nf_core is not yet present. Indeed. We can keep those sysctls there in bridge.ko and deprecated them in favour of br_netlink. I think we can add some IFLA_BRPORT_NF for the setlink command to replace the existing global proc nf-call-thing. We'll have to enhance the 'bridge' tool in iproute2 to support this. I can see this is packaged in testing already by debian at least. > Then, in two years or so, we would remove the autoload hook > in the packet procesing path. Agreed. By that time, we can kill the bridge.ko <-> br_netfilter.ko dependency and the /proc call-nf-bridge stuff in favour of br_netlink. Let me know if you still have any concern. Thanks. -- 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
