ACK/Cmnt: [SRU][D] Ensure /proc/sys/net/bridge folders (dis)appear appropriately

Stefan Bader stefan.bader at canonical.com
Mon Aug 12 13:48:44 UTC 2019


On 26.07.19 02:20, Connor Kuehl wrote:
> Note: Bionic required two additional patches in order for these to apply cleanly, one
> of which required minor backporting to use the updated wrappers/symbols.
> 
> BugLink: https://bugs.launchpad.net/bugs/1836910
> 
> Justification taken from the link above ^
> 
> SRU Justification
> 
> Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. 
> This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific 
> network namespace while doing so for bridges located in another network namespace.
> 
> Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network 
> namespace if the module is loaded and disappears from all network namespaces when the module is unloaded.
> 
> In doing so the patch makes the sysctls:
> 
> bridge-nf-call-arptables
> bridge-nf-call-ip6tables
> bridge-nf-call-iptables
> bridge-nf-filter-pppoe-tagged
> bridge-nf-filter-vlan-tagged
> bridge-nf-pass-vlan-input-dev
> 
> apply per network namespace.
> 
> Regression Potential: None, since this didn't use to work before. Otherwise limited to the br_netfilter module.
> The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether 
> bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can 
> already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be 
> possible to do this for all bridges in a network namespace via sysctls.
> 
> Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables.
> 

Since this is quite a bit of change and I agree with Seth disagreeing about the
regression potential. Especially since in the Bionic case there is change to the
generic bridge code. Can this cause issues with user-space tools? Like iproute2?

So for now only for Disco:

Acked-by: Stefan Bader <stefan.bader at canonical.com>



More information about the kernel-team mailing list