On Wed, Sep 24, 2014 at 2:31 AM, Nicolas DichtelNo, you're right. Will send a v3.
<nicolas.dichtel@xxxxxxxxx> wrote:
Le 23/09/2014 21:26, Andy Lutomirski a Ãcrit :
On Tue, Sep 23, 2014 at 6:20 AM, Nicolas Dichtel
<nicolas.dichtel@xxxxxxxxx> wrote:
The goal of this serie is to be able to multicast netlink messages with
an
attribute that identify a peer netns.
This is needed by the userland to interpret some informations contained
in
netlink messages (like IFLA_LINK value, but also some other attributes in
case
of x-netns netdevice (see also
http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
Ids are stored in the parent user namespace. These ids are valid only
inside
this user namespace. The user can retrieve these ids via a new netlink
messages,
but only if peer netns are in the same user namespace.
What about the parent / ancestors of the owning userns? Can processes
in those usernses see any form of netns id?
With this serie no. I'm not sure if ancestors really needs to be able to
get these ids. What is your opinion?
I might be missing some consideration here, but I would hope that ip
link would work correctly if I have a veth interface shared with a
netns that's in a child userns.