Thread (18 messages) 18 messages, 5 authors, 2014-07-15

Re: [RFC PATCH net-next 0/5] netns: allow to identify peer netns

From: Nicolas Dichtel <hidden>
Date: 2014-07-02 21:47:14

Le 02/07/2014 22:09, Eric W. Biederman a écrit :
Nicolas Dichtel [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help