APPLIED[E]/cmt: [SRU][B/D] Ensure /proc/sys/net/bridge folders (dis)appear appropriately

[Christian Brauner]

On Tue, Jul 30, 2019 at 12:01:08PM -0400, Seth Forshee wrote:
> +Cc Christian.
> 
> On Thu, Jul 25, 2019 at 05:20:46PM -0700, 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.
> 
> I don't agree with the regression potential here, which is particularly
> ironic given that the final patch fixes a user-after-free introduced by
> the patch before it (I'm sitting next to Christian as I type this and
> have already given him a hard time about that one). They are also fairly

I'm very happy that I only received a Not-Yet-Nacked-by which I vote
should be a new standard DCO-type.

> new, being upstream as of 5.3-rc1. So I think we need a better statement
> of regression potential and what kind of regression testing as been done
> before considering them for SRU.

I expanded the regression potential section and hopefully that'll turn
this into a Not-Nacked-by at least. ;)

> 
> Applied to eoan/master-next.

Thanks!
Christian