[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53B47DDE.7@6wind.com>
Date: Wed, 02 Jul 2014 23:47:10 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: netdev@...r.kernel.org, davem@...emloft.net,
stephen@...workplumber.org
Subject: Re: [RFC PATCH net-next 0/5] netns: allow to identify peer netns
Le 02/07/2014 22:09, Eric W. Biederman a écrit :
> Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:
>
>> 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)).
>>
>> Each network namespaces allocates its own ids for other netns (including
>> itself). The user can retrieve these ids via a new netlink messages, but only
>> if he has a FD which points to this netns. Dump is not implemented so that a
>> user cannot get the whole netns list.
>>
>> The goal of this RFC is mainly to validate the principle, ie patch 1/5 and 2/5.
>> Patch 3/5 and 4/5 shows an example of how to use these ids in rtnetlink
>> messages. And patch 5/5 shows that the netlink messages can be symetric between
>> a GET and a SET.
>
> This approach fundamentally breaks process migration, and calls for a
> namespace of namespaces.
Why does it call for a namespace of namespaces? Ids are different in each netns,
because each netns has its own list id.
Can you elaborate why it breaks the process migration?
Do you think that identifying a netns from another netns is fundamentally wrong?
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists