[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190617133440.mhnhtcwwraf53bl4@salvia>
Date: Mon, 17 Jun 2019 15:34:40 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Christian Brauner <christian@...uner.io>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
bridge@...ts.linux-foundation.org, tyhicks@...onical.com,
kadlec@...ckhole.kfki.hu, fw@...len.de, roopa@...ulusnetworks.com,
nikolay@...ulusnetworks.com, linux-kernel@...r.kernel.org,
richardrose@...gle.com, vapier@...omium.org, bhthompson@...gle.com,
smbarber@...omium.org, joelhockey@...omium.org,
ueberall@...menzentrisch.de
Subject: Re: [PATCH net-next v2 0/2] br_netfilter: enable in non-initial netns
On Mon, Jun 10, 2019 at 11:26:04PM +0200, Christian Brauner wrote:
[...]
> Over time I have seen multiple reports by users who want to run applications
> (Kubernetes e.g. via [1]) that require the br_netfilter module in
> non-initial network namespaces. There are *a lot* of issues for this. A
> shortlist including ChromeOS and other big users is found below under
> [2]! Even non-devs already tried to get more traction on this by
> commenting on the patchset (cf. [3]).
>
> Currently, the /proc/sys/net/bridge folder is only created in the
> initial network namespace. This patch series ensures 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.
Series applied, thanks Christian.
Powered by blists - more mailing lists