From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Eugene Yakubovich <eugene.yakubovich@coreos.com>, netdev@vger.kernel.org
Subject: Re: What are the intended semantics of IFLA_LINK_NETNSID?
Date: Thu, 26 Feb 2015 15:52:40 +0100 [thread overview]
Message-ID: <54EF3338.8000409@6wind.com> (raw)
In-Reply-To: <87wq34okb9.fsf@x220.int.ebiederm.org>
Le 26/02/2015 14:48, Eric W. Biederman a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
[snip]
>> The interface is first created in link_net and moved at the end in dest_net.
>>
>> IP tunnels interfaces (ipip, sit, ip6_tunnels, gre[v6]) does not use src_net,
>
> I am pretty certain that is simply something that was overlooked when
> cross network namespace support was added to those network device types.
> Right now I would be surprised if anything in userspace cares, so we can
> probably just change those device types to look at src_net from newlink.
At least, depending of the interface type, the behavior is not the same. Thus,
making all interfaces consistent seems good.
>
> Certainly for our sanity in maintaining rtnl_newlink finding a way to
> make that change would be preferable. Even if we ultimately have to add
> a flag that says only make src_net different from dev->net when
> IFLA_LINK_NETNSID is passed.
A flag is probably not needed, it's just a matter of passing src_net through
the functions that create the tunnel device.
>
> As making that change allows much more consistency in the code and
> allows us to get rid of an unnecessary dev_change_net_namespace.
Yes, I add this dev_change_net_namespace() to be independant of the interface
implementation (and thus beeing consistent whatever the interface type is used).
Nicolas
next prev parent reply other threads:[~2015-02-26 14:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 0:48 new link failing on duplicate names in different namespaces Eugene Yakubovich
2015-02-25 16:26 ` Nicolas Dichtel
2015-02-25 17:44 ` Eric W. Biederman
2015-02-26 5:29 ` Cong Wang
2015-02-26 5:56 ` Cong Wang
2015-02-26 9:14 ` Nicolas Dichtel
2015-02-26 13:55 ` Eric W. Biederman
2015-02-26 14:40 ` Nicolas Dichtel
2015-02-27 0:22 ` Cong Wang
2015-02-25 19:03 ` What are the intended semantics of IFLA_LINK_NETNSID? Eric W. Biederman
2015-02-26 5:07 ` Cong Wang
2015-02-26 8:55 ` Nicolas Dichtel
2015-02-26 13:48 ` Eric W. Biederman
2015-02-26 14:52 ` Nicolas Dichtel [this message]
2015-02-26 22:19 ` [PATCH net 1/2] net: Verify permission to dest_net in newlink Eric W. Biederman
2015-02-26 22:20 ` [PATCH net 2/2] net: Verify permission to link_net " Eric W. Biederman
2015-02-27 9:03 ` Nicolas Dichtel
2015-02-28 20:15 ` David Miller
2015-02-27 9:03 ` [PATCH net 1/2] net: Verify permission to dest_net " Nicolas Dichtel
2015-02-28 20:15 ` David Miller
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=54EF3338.8000409@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=ebiederm@xmission.com \
--cc=eugene.yakubovich@coreos.com \
--cc=netdev@vger.kernel.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.