Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3142153imu; Wed, 7 Nov 2018 05:50:50 -0800 (PST) X-Google-Smtp-Source: AJdET5cG9kV89n4rytIAzjKcP+yvptN4nD4CVmUrvccPkGyrCXYHyZTTfay8MS+nS27enACcEONX X-Received: by 2002:a17:902:b688:: with SMTP id c8-v6mr317739pls.306.1541598650277; Wed, 07 Nov 2018 05:50:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541598650; cv=none; d=google.com; s=arc-20160816; b=XybgHmgW+gTIUKUXyFfbGaFto8atCEtF/21vejO1dG0wQlWPXopi8J1IS45DnWoL0H 3PPVFMdAFyW9CTUpRYJ+7fxYxGUufdAxYe3FV4e8JnD2Z+Zz/NBfx+l4CV/nBkWdkgmf kn9Sv6/2/WnOTUekvFDBKTnZEKdfud6vPVoNHPMpIDD2RdM7EE+KBQoUTwq76jdpz5gJ vGBXmrBuNzf/DHbHunnhuLBllg9Krs4Tmpcd19C3ImE8WqcC4eR+wWzX+oLsjsqD9VCC 8NrY9S7v0UGMf9q670av1AcNw1h/sgDSKGy4DD/t59K80Ee7IKA2xJjL52eCNYU3bgV+ WFFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=uJ6ZT8E5/I+O1wiMOAR9lKmGCXZmgtKp4kCHVfIL2j4=; b=zKNfDwoIr61Ij1fUOOlww7uNAKemuitsQpdy4/yiRX9jhO+Ik8IA3OFaaLGIbQkATB r+L2kAUx99Kx6AXtyX02wc4OjzEYiSVwpRnGw1DuWNfg3CgMjPSleMmji4Z/fIaDq7cP kdI7bnZotqxrab9oX6RqhwF1mQ9+nmq5jgbhObCBaWQfZpHNZnV23dDuEcJiI6wwvzoN a/K9Cx4ItMfuvA0AXhjGG4cHaO5ROXjbL9wj4tFxGZcl6p3vo4dEgkaf8x1gtY3oHMJ9 U4AgzWM6X/70f1pQ3PGV30iz2ud2mMg+xC/wgN1/orzsj2XpmI1WDtGwyRm3Iq1Ng80b xEPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=Oy8s3hhg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p20-v6si666220plq.379.2018.11.07.05.50.35; Wed, 07 Nov 2018 05:50:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=Oy8s3hhg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727735AbeKGXT7 (ORCPT + 99 others); Wed, 7 Nov 2018 18:19:59 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:43110 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727168AbeKGXT7 (ORCPT ); Wed, 7 Nov 2018 18:19:59 -0500 Received: by mail-wr1-f66.google.com with SMTP id y3-v6so17172334wrh.10 for ; Wed, 07 Nov 2018 05:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uJ6ZT8E5/I+O1wiMOAR9lKmGCXZmgtKp4kCHVfIL2j4=; b=Oy8s3hhgyzVgyIiOzCyqpRA14stnzybiMKyY2OaXtZEfahTJpk0hPolFrYiv9bEl4Z xBq1uj+trqf0WmQC4xTlImUrcOgRXo5FOlZwYT8EhsmZwshUskAkVQyFrU+1ZSI8gA3a gFnFjkd66VKny8RO+xhfHiqJ5s+JYMREFGjsLFTvVB3VCKWiuTvcqqK2oPTiQyLTRiSu tvBS+p4tMJxLI5AQzsuXR6LoSihLYmnbQrqWzn8XMfTgm+av/X7HZjOuRSiK9X5sjXaQ FYZd/QoRY1YxwgPzBj0DJEGyUiIpqeOM74qzgECyjInmR1ZMt5/8M2SzMOZBBqdf6VvG YbfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uJ6ZT8E5/I+O1wiMOAR9lKmGCXZmgtKp4kCHVfIL2j4=; b=QJAyLEclN+D/7aFR65xqO7e7xO4/WDoFV8hWMWABibhLDXPwTa/2AA/fQk/9ynk1k2 KxWS9cgjkf6+/EBn3KFu9zxdoSpjl2GqC6FJ83SSNY2HUCeONDLQhhrOaEpjAsJFiV4b 1kAF0FWZPE/BI7wTZ/7FV5dzSbdQ2oWijG79HnFMrEqJbMwRlNl79hBh1rUGFmktzjK0 3MpSzKWTo99C/ViNcWeMLOxvJRvmCbN7lJ8O+DfYB00ccdlOmNbdHA0144gFMtgxpVn/ f714WnwJlDa4nrERMd7D03m1wEBjBMN6du+J21ArzAqD2a+zOymNjOf2zpSyyPqpzYuw Jzhg== X-Gm-Message-State: AGRZ1gLI2A8UNsYywrnEm6nFbZ08k4yw1Zta9oDpn/M58aNA+T7vA0qv pgDO1h82fcy+w0bL5cdrXKNs0A== X-Received: by 2002:adf:8361:: with SMTP id 88-v6mr303071wrd.192.1541598570442; Wed, 07 Nov 2018 05:49:30 -0800 (PST) Received: from localhost.localdomain ([2a02:8070:8895:9700:887:8ecc:df73:24eb]) by smtp.gmail.com with ESMTPSA id y83-v6sm1206778wmb.20.2018.11.07.05.49.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 05:49:29 -0800 (PST) From: Christian Brauner To: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, bridge@lists.linux-foundation.org Cc: tyhicks@canonical.com, pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de, roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com, Christian Brauner Subject: [PATCH net-next 0/2] br_netfilter: enable in non-initial netns Date: Wed, 7 Nov 2018 14:48:57 +0100 Message-Id: <20181107134859.19896-1-christian@brauner.io> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey everyone, 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 [2], [3], [4], [5] (There are more issues where this requirement is reported.). 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. The patch series also 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. This unblocks some 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. The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether a bridge device inside their network namespace is supposed to go through iptables et al. or not. Also, this can already be done 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. Thanks! Christian [1]: https://github.com/zimmertr/Bootstrap-Kubernetes-with-Ansible [2]: https://github.com/lxc/lxd/issues/5193 [3]: https://discuss.linuxcontainers.org/t/bridge-nf-call-iptables-and-swap-error-on-lxd-with-kubeadm/2204 [4]: https://github.com/lxc/lxd/issues/3306 [5]: https://gitlab.com/gitlab-org/gitlab-runner/issues/3705 Christian Brauner (2): br_netfilter: add struct netns_brnf br_netfilter: namespace bridge netfilter sysctls include/net/net_namespace.h | 3 + include/net/netfilter/br_netfilter.h | 3 +- include/net/netns/netfilter.h | 16 +++ net/bridge/br_netfilter_hooks.c | 166 ++++++++++++++++++--------- net/bridge/br_netfilter_ipv6.c | 2 +- 5 files changed, 134 insertions(+), 56 deletions(-) -- 2.19.1