All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasily Averin <vvs-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Bart De Schuymer
	<bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>,
	"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: question about default values for per-namespace settings
Date: Thu, 15 May 2014 13:01:52 +0400	[thread overview]
Message-ID: <53748280.60906@parallels.com> (raw)
In-Reply-To: <53727246.4050306-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>

Dear Tejun,

how do you think, which defaults should be used for per-namespace settings in general case
and for per-netns sysctls especially? Do we have some common position about this or
perhaps we already have some setting that allows to select desired behavior?

I'm preparing patch that makes per-netns sysctls in br_netfilter,
to be able to enable/disable br-nf-call processing in each network namespace independently.

I've initialized sysctl values in each netns by system defaults, like it was done in similar cases.
However Bart pointed that "this does introduce a bit of backwards incompatibility":
currently all netns shares the br_netfilter sysctl settings applied in init_net.

From OpenVz point of view containers should be properly isolated,
should have predictable initial configuration
and should not depend on settings applied in another containers.
On the other hand independent containers is only one of possible usecases,
and I have no strong objections against Bart's proposal. Frankly speaking
initially I've planned to copy setting from init_net too.

To make possible both variants I can introduce one more setting,
it allows to specify desired behavior:
to use system defaults or to copy current settings from init_net.

However probably the same dilemma was observed in another subsystems?
Perhaps this selector already exists?

If isn't, how do you think, should I introduce some new global parameter,
or may be it should be some local bridge-only-related setting?

Thank you,
	Vasily Averin

you can find some more details about my patch in netfilter-devel@
[PATCH RFC v3 2/2] br_netfilter: per-netns copy of structure for sysctl flags
On 05/13/2014 11:28 PM, Bart De Schuymer wrote:
> Vasily Averin schreef op 12/05/2014 22:11:
>> On 05/12/2014 11:04 PM, Bart De Schuymer wrote:
>>> Vasily Averin schreef op 12/05/2014 18:32:
>>>> pernet_operations creates per-netns copy of common structure for sysctl flags
>>>> and initialize it values taken from init_brnf_net.
>>>>
>>>> Signed-off-by: Vasily Averin <vvs-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>>>
>>>> +static int __net_init brnf_net_init(struct net *net)
>>>> +{
>>>> +    struct brnf_net *bn = brnf_net(net);
>>>> +
>>>> +    memcpy(bn, &init_brnf_net, sizeof(struct brnf_net));
>>>> +    bn->net = net;
>>>> +    return brnf_sysctl_net_register(bn);
>>>
>>> This does introduce a bit of backwards incompatibility (easily fixed
>>> by adapting scripts), but this is really unavoidable when
>>> transforming an existing global configuration to a per-netns
>>> configuration. I'm ok with it.
>>
>> Could you please explain, which backward incompatibility you mean here?
>> Nobody changes values init_brnf_net,
>> init_net have own copy, like any other network namespaces.
> 
> Well, init_brnf_net is never written to, so it keeps the default flags.
> If a new netns is created, a copy of the contents of init_brnf_net is made. So, whenever a netns is created, it starts with the default flags (e.g. brnf_call_iptables is always 1 for a newly created netns).
> 
> In the current kernel, when a new netns is created, the configuration of the main netns is used (the proc system doesn't even show the flags in the created netns): if brnf_call_iptables is 0 before the new netns is created, iptables won't see bridged IP traffic in the new netns.
> With your patch, this behaviour will change.
> 
> It's possible to alter your patch to keep the same behaviour as before at netns creation, but always starting from the same defaults is cleaner.

WARNING: multiple messages have this Message-ID (diff)
From: Vasily Averin <vvs-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Bart De Schuymer
	<bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>,
	"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: question about default values for per-namespace settings
Date: Thu, 15 May 2014 13:01:52 +0400	[thread overview]
Message-ID: <53748280.60906@parallels.com> (raw)
In-Reply-To: <53727246.4050306-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>

Dear Tejun,

how do you think, which defaults should be used for per-namespace settings in general case
and for per-netns sysctls especially? Do we have some common position about this or
perhaps we already have some setting that allows to select desired behavior?

I'm preparing patch that makes per-netns sysctls in br_netfilter,
to be able to enable/disable br-nf-call processing in each network namespace independently.

I've initialized sysctl values in each netns by system defaults, like it was done in similar cases.
However Bart pointed that "this does introduce a bit of backwards incompatibility":
currently all netns shares the br_netfilter sysctl settings applied in init_net.

>From OpenVz point of view containers should be properly isolated,
should have predictable initial configuration
and should not depend on settings applied in another containers.
On the other hand independent containers is only one of possible usecases,
and I have no strong objections against Bart's proposal. Frankly speaking
initially I've planned to copy setting from init_net too.

To make possible both variants I can introduce one more setting,
it allows to specify desired behavior:
to use system defaults or to copy current settings from init_net.

However probably the same dilemma was observed in another subsystems?
Perhaps this selector already exists?

If isn't, how do you think, should I introduce some new global parameter,
or may be it should be some local bridge-only-related setting?

Thank you,
	Vasily Averin

you can find some more details about my patch in netfilter-devel@
[PATCH RFC v3 2/2] br_netfilter: per-netns copy of structure for sysctl flags
On 05/13/2014 11:28 PM, Bart De Schuymer wrote:
> Vasily Averin schreef op 12/05/2014 22:11:
>> On 05/12/2014 11:04 PM, Bart De Schuymer wrote:
>>> Vasily Averin schreef op 12/05/2014 18:32:
>>>> pernet_operations creates per-netns copy of common structure for sysctl flags
>>>> and initialize it values taken from init_brnf_net.
>>>>
>>>> Signed-off-by: Vasily Averin <vvs-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>>>
>>>> +static int __net_init brnf_net_init(struct net *net)
>>>> +{
>>>> +    struct brnf_net *bn = brnf_net(net);
>>>> +
>>>> +    memcpy(bn, &init_brnf_net, sizeof(struct brnf_net));
>>>> +    bn->net = net;
>>>> +    return brnf_sysctl_net_register(bn);
>>>
>>> This does introduce a bit of backwards incompatibility (easily fixed
>>> by adapting scripts), but this is really unavoidable when
>>> transforming an existing global configuration to a per-netns
>>> configuration. I'm ok with it.
>>
>> Could you please explain, which backward incompatibility you mean here?
>> Nobody changes values init_brnf_net,
>> init_net have own copy, like any other network namespaces.
> 
> Well, init_brnf_net is never written to, so it keeps the default flags.
> If a new netns is created, a copy of the contents of init_brnf_net is made. So, whenever a netns is created, it starts with the default flags (e.g. brnf_call_iptables is always 1 for a newly created netns).
> 
> In the current kernel, when a new netns is created, the configuration of the main netns is used (the proc system doesn't even show the flags in the created netns): if brnf_call_iptables is 0 before the new netns is created, iptables won't see bridged IP traffic in the new netns.
> With your patch, this behaviour will change.
> 
> It's possible to alter your patch to keep the same behaviour as before at netns creation, but always starting from the same defaults is cleaner.

  parent reply	other threads:[~2014-05-15  9:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <536FD0FD.8010204@pandora.de>
2014-05-12 12:56 ` [PATCH RFC v2 00/11] per-netns sysctl for br_netfilter Vasily Averin
     [not found] ` <cover.1399897184.git.vvs@openvz.org>
2014-05-12 12:56   ` [PATCH RFC v2 01/11] br_netfilter: brnf_net structure for sysctl setting Vasily Averin
2014-05-12 12:56   ` [PATCH RFC v2 02/11] br_netfilter: default sysctl settings in init_brnf_net Vasily Averin
2014-05-12 14:07     ` Patrick McHardy
2014-05-12 16:31       ` [PATCH RFC v3 0/2] per-netns sysctl for br_netfilter Vasily Averin
2014-05-29 12:28         ` Pablo Neira Ayuso
2014-05-30 10:04           ` Vasily Averin
     [not found]       ` <cover.1399909529.git.vvs@openvz.org>
2014-05-12 16:31         ` [PATCH RFC v3 1/2] br_netfilter: common structure for sysctl flags Vasily Averin
2014-05-12 16:32         ` [PATCH RFC v3 2/2] br_netfilter: per-netns copy of " Vasily Averin
2014-05-12 19:04           ` Bart De Schuymer
2014-05-12 20:11             ` Vasily Averin
2014-05-13 19:28               ` Bart De Schuymer
     [not found]                 ` <53727246.4050306-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
2014-05-15  9:01                   ` Vasily Averin [this message]
2014-05-15  9:01                     ` question about default values for per-namespace settings Vasily Averin
2014-05-15 17:48                     ` Tejun Heo
     [not found]                       ` <20140515174850.GB20738-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2014-05-16 11:16                         ` Maciej Żenczykowski
     [not found]                     ` <53748280.60906-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-15 11:02                       ` Serge Hallyn
2014-05-15 17:48                       ` Tejun Heo
2014-05-19 19:30                       ` Bart De Schuymer
2014-05-19 19:30                     ` Bart De Schuymer
     [not found]                       ` <537A5BD1.90906-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
2014-06-24  8:21                         ` Vasily Averin
     [not found]                           ` <53A934F1.7040906-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-06-25  7:45                             ` Eric W. Biederman
2014-06-25  7:45                               ` Eric W. Biederman
2014-05-12 12:57   ` [PATCH RFC v2 03/11] br_netfilter: brnf_flag macro Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 04/11] br_netfilter: switch sysctl call_arptables to init_brnf_net Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 05/11] br_netfilter: switch sysctls call_iptables and call_ip6tables " Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 06/11] br_netfilter: switch sysctl filter_vlan_tagged " Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 07/11] br_netfilter: switch sysctl filter_pppoe_tagged " Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 08/11] br_netfilter: switch sysctl pass_vlan_indev " Vasily Averin
2014-05-12 12:57   ` [PATCH RFC v2 09/11] br_netfilter: added pernet_operations without sysctl registration Vasily Averin
2014-05-12 12:58   ` [PATCH RFC v2 10/11] br_netfilter: per-netns " Vasily Averin
2014-05-12 12:58   ` [PATCH RFC v2 11/11] br_netfilter: switch all sysctls to per-netns processing Vasily Averin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53748280.60906@parallels.com \
    --to=vvs-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
    --cc=bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.