Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2323205ybi; Sun, 9 Jun 2019 08:57:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqz9etFw9CAj+YAFJC1NNLXsm1wncP6SNx8hs+iF0uaUkHS2fR+KjXxXEZvJDFwFp5bthGGr X-Received: by 2002:a17:902:8303:: with SMTP id bd3mr66059442plb.240.1560095878065; Sun, 09 Jun 2019 08:57:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560095878; cv=none; d=google.com; s=arc-20160816; b=Q8YCi2vSQHqSPt8wiLw/Vth8wCsi+dfof8uHbWlY3idxB51QbH8KTtdyZLT9Sp5MNR MEuiIgFcC93CekvOI6604O1yYP2nVYv+ChlvxyEbI87Uq53WL3Djj9J318aYG9ZBG19J u5itx5rT4xzXRxORuAtAkkPd749iSSqmj+iLdMngy/rrEss6i+hRPJCOgUDpvpneNNlL 5ebYKYmz9Kwq48pCNT8tSkF6hKvyeOpgoe700DI9Y0GTp7tG/OlieDFFdGzHCdrw4312 A3KzyX/x6a0tSVLa3ultccQfI13VcTs31owzGH9Iekx0aJK3ShOTdj3ueUGHPIblKpka zbEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=pMFPZMSiGklfaZyfuFOGH+2W0X1p8u7TpG+RYN4ZXnY=; b=rB8ghIwiwnf/chAmrhOcewjHGw/tdpIX7UvJCj7jdJrs1NEEZBgHxvC+DkPdeQYL0E bbmZVtbtKs9i3OMp2C42sjzt6uAa4wt2hl+E9W2BcJx+8tBXHaeRTBrjEJrVZL0qa4as dJtteWwHiAz2FvM2FFMNRVzdC5fGLAiJXIZfYJ9foIoDu11cN1yZ5iJBuJxxtA9lVgYa 58NUJUkFzvHYEuSromVTMhvlzOm7OuWUe+N43eIvGFOooMXuD03qGLzGO7EelVzkHnFu LLauFafPMMsjeKfFaOKtmTtj3xRHVMSSdIcMqJleg3ESf1/QRvnm9NmjuO0G58jwnzm/ cJ/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=EXmd3v5o; 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 cj11si7647303plb.373.2019.06.09.08.57.26; Sun, 09 Jun 2019 08:57:58 -0700 (PDT) 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=EXmd3v5o; 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 S1728970AbfFIPoX (ORCPT + 99 others); Sun, 9 Jun 2019 11:44:23 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:39502 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728635AbfFIPoX (ORCPT ); Sun, 9 Jun 2019 11:44:23 -0400 Received: by mail-ed1-f68.google.com with SMTP id m10so10396100edv.6 for ; Sun, 09 Jun 2019 08:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=pMFPZMSiGklfaZyfuFOGH+2W0X1p8u7TpG+RYN4ZXnY=; b=EXmd3v5obVkBPoKbED/ljCt8sh5huVmTgTEujveNN6i39S4CCp7O401AeWJlt0MXPL rjFmwoNnZKuzleSsdaYCDsRFm3MJSvJhIoGBbY+vsjEZIyMlYCz+QfYmBRuYOK46zxIA q8MV3LVdz/l8m8L/tAFdKEnQ0k2GVoHT05JxNQ370QxtZSKN0m7n4DrpN0aYmkazGElI eoD9qXhK3Z8kR6OD930EKB89POnoOJWbwleOlz6TPHsJkmpoAoex22apfAlQai2Bz8rO hJUGi5hIw43EirJpBm1j7e/lHQA+3kVb2DREdowJbOi9feiwF/xdfk1WivCifhXFI25k Yr2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pMFPZMSiGklfaZyfuFOGH+2W0X1p8u7TpG+RYN4ZXnY=; b=tnPJ/OQlCPZPeDUo32x1EaJMbxehUDQOtmmOwzX7H/McsfYkWBJPuL1nYH0hcYZYRc WdDfSuaOA0qxd3uSgdx0eZmm6x4+ctGJUKuq0xq5EqpGV08fxJawp9NgCAQIPe/UzYd9 /3f12Uaycwro5jGltugkiHzlN0wgLPn5xlAsojlsZy0CyMH8BryhzdtpJiV3qrdh0W3n pxfwBmt1g6zyrN5k3WPvxWB5Eefwfm7Ruk8N6Rv3PFBBZ/jOBNKlK8v4hSr/eu+vgOI6 9hXWoyHVsd5ga4ubAMb1cBIcR8w+1oeUcUxIdz0Bb+83kkWWY3s6C9co4hETWwCIQQt2 fZUw== X-Gm-Message-State: APjAAAWuRKZAiInGIw+dtYkgQ2Xt5MMlo8HEId7qVvF3FSsPS+jjcn9F o5N0Mwl01cO5F8Perxbg8l7qIw== X-Received: by 2002:a17:906:4f87:: with SMTP id o7mr55245469eju.281.1560095060514; Sun, 09 Jun 2019 08:44:20 -0700 (PDT) Received: from brauner.io ([2a02:8109:9cc0:6dac:cd8f:f6e9:1b84:bbb1]) by smtp.gmail.com with ESMTPSA id z3sm2102247edh.71.2019.06.09.08.44.17 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 09 Jun 2019 08:44:19 -0700 (PDT) Date: Sun, 9 Jun 2019 17:44:16 +0200 From: Christian Brauner To: Pablo Neira Ayuso Cc: Stephen Hemminger , davem@davemloft.net, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, bridge@lists.linux-foundation.org, tyhicks@canonical.com, kadlec@blackhole.kfki.hu, fw@strlen.de, roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com, linux-kernel@vger.kernel.org, richardrose@google.com, vapier@chromium.org, bhthompson@google.com, smbarber@chromium.org, joelhockey@chromium.org, ueberall@themenzentrisch.de Subject: Re: [PATCH RESEND net-next 1/2] br_netfilter: add struct netns_brnf Message-ID: <20190609154415.kkzmzl2jp5esoczu@brauner.io> References: <20190606114142.15972-1-christian@brauner.io> <20190606114142.15972-2-christian@brauner.io> <20190606081440.61ea1c62@hermes.lan> <20190606151937.mdpalfk7urvv74ub@brauner.io> <20190606163035.x7rvqdwubxiai5t6@salvia> <20190607132516.q3zwmzrynvqo7mzn@brauner.io> <20190607142858.vgkljqohn34rxhe2@salvia> <20190607144343.nzdlnuo4csllcy7q@salvia> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190607144343.nzdlnuo4csllcy7q@salvia> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 07, 2019 at 04:43:43PM +0200, Pablo Neira Ayuso wrote: > On Fri, Jun 07, 2019 at 04:28:58PM +0200, Pablo Neira Ayuso wrote: > > On Fri, Jun 07, 2019 at 03:25:16PM +0200, Christian Brauner wrote: > > > On Thu, Jun 06, 2019 at 06:30:35PM +0200, Pablo Neira Ayuso wrote: > > > > On Thu, Jun 06, 2019 at 05:19:39PM +0200, Christian Brauner wrote: > > > > > On Thu, Jun 06, 2019 at 08:14:40AM -0700, Stephen Hemminger wrote: > > > > > > On Thu, 6 Jun 2019 13:41:41 +0200 > > > > > > Christian Brauner wrote: > > > > > > > > > > > > > +struct netns_brnf { > > > > > > > +#ifdef CONFIG_SYSCTL > > > > > > > + struct ctl_table_header *ctl_hdr; > > > > > > > +#endif > > > > > > > + > > > > > > > + /* default value is 1 */ > > > > > > > + int call_iptables; > > > > > > > + int call_ip6tables; > > > > > > > + int call_arptables; > > > > > > > + > > > > > > > + /* default value is 0 */ > > > > > > > + int filter_vlan_tagged; > > > > > > > + int filter_pppoe_tagged; > > > > > > > + int pass_vlan_indev; > > > > > > > +}; > > > > > > > > > > > > Do you really need to waste four bytes for each > > > > > > flag value. If you use a u8 that would work just as well. > > > > > > > > > > I think we had discussed something like this but the problem why we > > > > > can't do this stems from how the sysctl-table stuff is implemented. > > > > > I distinctly remember that it couldn't be done with a flag due to that. > > > > > > > > Could you define a pernet_operations object? I mean, define the id and size > > > > fields, then pass it to register_pernet_subsys() for registration. > > > > Similar to what we do in net/ipv4/netfilter/ipt_CLUSTER.c, see > > > > clusterip_net_ops and clusterip_pernet() for instance. > > > > > > Hm, I don't think that would work. The sysctls for br_netfilter are > > > located in /proc/sys/net/bridge under /proc/sys/net which is tightly > > > integrated with the sysctls infrastructure for all of net/ and all the > > > folder underneath it including "core", "ipv4" and "ipv6". > > > I don't think creating and managing files manually in /proc/sys/net is > > > going to fly. It also doesn't seem very wise from a consistency and > > > complexity pov. I'm also not sure if this would work at all wrt to file > > > creation and reference counting if there are two different ways of > > > managing them in the same subfolder... > > > (clusterip creates files manually underneath /proc/net which probably is > > > the reason why it gets away with it.) > > > > br_netfilter is now a module, and br_netfilter_hooks.c is part of it > > IIRC, this file registers these sysctl entries from the module __init > > path. > > > > It would be a matter of adding a new .init callback to the existing > > brnf_net_ops object in br_netfilter_hooks.c. Then, call > > register_net_sysctl() from this .init callback to register the sysctl > > entries per netns. > > Actually, this is what you patch is doing... > > > There is already a brnf_net area that you can reuse for this purpose, > > to place these pernetns flags... > > > > struct brnf_net { > > bool enabled; > > }; > > > > which is going to be glad to have more fields (under the #ifdef > > CONFIG_SYSCTL) there. > > ... except that struct brnf_net is not used to store the ctl_table. > > So what I'm propose should be result in a small update to your patch 2/2. Actually not, I think. I had to rework it substantially but I think the outcome is quite nice. :) I'll send a new version now/today. :) Thanks! Christian