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

[Christian Brauner]

The whole regression potential section has been completely reworked as requested by Seth.
That should be pretty obvious from the updated launchpad BugLink.

On August 12, 2019 3:48:44 PM GMT+02:00, Stefan Bader <stefan.bader at canonical.com> wrote:
>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>
>
>-- 
>kernel-team mailing list
>kernel-team at lists.ubuntu.com
>https://lists.ubuntu.com/mailman/listinfo/kernel-team

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20190812/0bf3ebd9/attachment-0001.html>