From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dichtel Subject: Re: [PATCH net-next v4 0/4] netns: allow to identify peer netns Date: Wed, 05 Nov 2014 15:23:00 +0100 Message-ID: <545A32C4.7070108@6wind.com> References: <1412257690-31253-1-git-send-email-nicolas.dichtel@6wind.com> <1414682728-4532-1-git-send-email-nicolas.dichtel@6wind.com> <871tpph03k.fsf@x220.int.ebiederm.org> <54535B00.5090708@6wind.com> <87wq7g831b.fsf@x220.int.ebiederm.org> Reply-To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <87wq7g831b.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org, stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org, cwang-xCSkyg8dI+0RB7SZvlqPiA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org List-Id: containers.vger.kernel.org TGUgMzEvMTAvMjAxNCAyMDoxNCwgRXJpYyBXLiBCaWVkZXJtYW4gYSDDqWNyaXQgOgo+IE5pY29s YXMgRGljaHRlbCA8bmljb2xhcy5kaWNodGVsQDZ3aW5kLmNvbT4gd3JpdGVzOgo+Cj4+IExlIDMw LzEwLzIwMTQgMTk6NDEsIEVyaWMgVy4gQmllZGVybWFuIGEgw6ljcml0IDoKPj4+IE5pY29sYXMg RGljaHRlbCA8bmljb2xhcy5kaWNodGVsQDZ3aW5kLmNvbT4gd3JpdGVzOgo+Pj4KPj4+PiBUaGUg Z29hbCBvZiB0aGlzIHNlcmllIGlzIHRvIGJlIGFibGUgdG8gbXVsdGljYXN0IG5ldGxpbmsgbWVz c2FnZXMgd2l0aCBhbgo+Pj4+IGF0dHJpYnV0ZSB0aGF0IGlkZW50aWZ5IGEgcGVlciBuZXRucy4K Pj4+PiBUaGlzIGlzIG5lZWRlZCBieSB0aGUgdXNlcmxhbmQgdG8gaW50ZXJwcmV0IHNvbWUgaW5m b3JtYXRpb25zIGNvbnRhaW5lZCBpbgo+Pj4+IG5ldGxpbmsgbWVzc2FnZXMgKGxpa2UgSUZMQV9M SU5LIHZhbHVlLCBidXQgYWxzbyBzb21lIG90aGVyIGF0dHJpYnV0ZXMgaW4gY2FzZQo+Pj4+IG9m IHgtbmV0bnMgbmV0ZGV2aWNlIChzZWUgYWxzbwo+Pj4+IGh0dHA6Ly90aHJlYWQuZ21hbmUub3Jn L2dtYW5lLmxpbnV4Lm5ldHdvcmsvMzE1OTMzL2ZvY3VzPTMxNjA2NCBhbmQKPj4+PiBodHRwOi8v dGhyZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5rZXJuZWwuY29udGFpbmVycy8yODMwMS9mb2N1 cz00MjM5KSkuCj4+Pj4KPj4+PiBJZHMgb2YgcGVlciBuZXRucyBhcmUgc2V0IGJ5IHVzZXJsYW5k IHZpYSBhIG5ldyBnZW5sIG1lc3NhZ2VzLiBUaGVzZSBpZHMgYXJlCj4+Pj4gc3RvcmVkIHBlciBu ZXRucyBhbmQgYXJlIGxvY2FsIChpZSBvbmx5IHZhbGlkIGluIHRoZSBuZXRucyB3aGVyZSB0aGV5 IGFyZSBzZXQpLgo+Pj4+IFRvIGF2b2lkIGFsbG9jYXRpbmcgYW4gaW50IGZvciBlYWNoIHBlZXIg bmV0bnMsIEkgdXNlIGlkcl9mb3JfZWFjaCgpIHRvIHJldHJpZXZlCj4+Pj4gdGhlIGlkIG9mIGEg cGVlciBuZXRucy4gTm90ZSB0aGF0IGl0IHdpbGwgYmUgcG9zc2libGUgdG8gYWRkIGEgdGFibGUg KHN0cnVjdCBuZXQKPj4+PiAtPiBpZCkgbGF0ZXIgdG8gb3B0aW1pemUgdGhpcyBsb29rdXAgaWYg bmVlZGVkLgo+Pj4+Cj4+Pj4gUGF0Y2ggMS80IGludHJvZHVjZXMgdGhlIG5ldGxpbmsgQVBJIG1l Y2hhbmlzbSB0byBzZXQgYW5kIGdldCB0aGVzZSBpZHMuCj4+Pj4gUGF0Y2ggMi80IGFuZCAzLzQg aW1wbGVtZW50cyBhbiBleGFtcGxlIG9mIGhvdyB0byB1c2UgdGhlc2UgaWRzIGluIHJ0bmV0bGlu awo+Pj4+IG1lc3NhZ2VzLiBBbmQgcGF0Y2ggNC80IHNob3dzIHRoYXQgdGhlIG5ldGxpbmsgbWVz c2FnZXMgY2FuIGJlIHN5bWV0cmljIGJldHdlZW4KPj4+PiBhIEdFVCBhbmQgYSBTRVQuCj4+Pj4K Pj4+PiBpcHJvdXRlMiBwYXRjaGVzIGFyZSBhdmFpbGFibGUsIEkgY2FuIHNlbmQgdGhlbSBvbiBk ZW1hbmQuCj4+Pgo+Pj4gQSBxdWljayByZXBseS4gIEkgdGhpbmsgdGhpcyBwYXRjaHNldCBpcyBp biB0aGUgcmlnaHQgZ2VuZXJhbCBkaXJlY3Rpb24uCj4+PiBUaGVyZSBhcmUgc29tZSBvZGRiYWxs IGRldGFpbHMgdGhhdCBzZWVtIG9kZC9hd2t3YXJkIHRvIG1lIHN1Y2ggYXMgdXNpbmcKPj4+IGdl bmV0bGluayBpbnN0ZWFkIG9mIHJ0bmV0bGluayB0byBnZXQgYW5kIHNldCB0aGUgaWRzLCBhbmQg bm90IGhhdmluZwo+Pj4gaWRzIGlmIHRoZXkgYXJlIG5vdCBzZXQgKHRoYXQgZmVlbHMgbGlrZSBh IG1haW50ZW5hbmNlL3VzYWJpbGl0eSBjaGFsbGVuZ2UpLgo+PiBObyBwcm9ibGVtIHRvIHVzZSBy dG5ldGxpbmssIGluIGZhY3QsIEkgaGVzaXRhdGVkLgo+Pgo+PiBGb3IgdGhlIHNlY29uZCBwb2lu dCwgSSdtIG5vdCBzdXJlIHRvIGZvbGxvdyB5b3U6IGhvdyB0byBoYXZlIGFuIGlkLCB3aGljaCB3 aWxsCj4+IG5vdCBicmVhayBtaWdyYXRpb24sIHdpdGhvdXQgYXNraW5nIHRoZSB1c2VyIHRvIHNl dCBpdD8KPgo+IFdlIGhhdmUgdGhhdCBzaXR1dGF0aW9uIHdpdGggaWZpbmRleCBhbHJlYWR5LiAg QmFzaWNhbGx5IHRoZSB0aG91Z2h0IGlzCj4gdG8gYWxsb3cgYW4gaWQgdG8gYmUgc2V0LCBidXQg YWxzbyBhbGxvdyBhbiBpZCB0byBiZSBhdXRvLWdlbmVyYXRlZCBpZgo+IHdlIHVzZSBhbiBuYW1l c3BhY2Ugd2l0aG91dCBhbiBpZCBiZWluZyBzZXQuCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdCwgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB3ZSB3YW50IHRvIGhpZGUgc29tZQpuZXRucy4K RG8geW91IHRoaW5rIHdlIGNhbiBnZW5lcmF0ZSBhbiBpZCBmb3IgZWFjaCBuZXRucyB0aGF0IGRv ZXMgbm90IGhhdmUgb25lIGFuZApyZWx5aW5nIG9uIHRoZSBmYWN0IHRoYXQgdGhpcyBpZCBoYXMg bm8gbWVhbmluZyB1bmxlc3MgeW91IGhhdmUgYSBuZXRucyBmaWxlCmRlc2NyaXB0b3IgdGhhdCBh bGxvdyB5b3UgdG8gZ2V0IHRoZSBpZCBvZiB0aGlzIG5ldG5zPwoKClJlZ2FyZHMsCk5pY29sYXMK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29udGFpbmVy cyBtYWlsaW5nIGxpc3QKQ29udGFpbmVyc0BsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRw czovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755166AbaKEOXH (ORCPT ); Wed, 5 Nov 2014 09:23:07 -0500 Received: from mail-wg0-f41.google.com ([74.125.82.41]:60123 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755141AbaKEOXD (ORCPT ); Wed, 5 Nov 2014 09:23:03 -0500 Message-ID: <545A32C4.7070108@6wind.com> Date: Wed, 05 Nov 2014 15:23:00 +0100 From: Nicolas Dichtel Reply-To: nicolas.dichtel@6wind.com Organization: 6WIND User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Eric W. Biederman" CC: netdev@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, davem@davemloft.net, stephen@networkplumber.org, akpm@linux-foundation.org, luto@amacapital.net, cwang@twopensource.com Subject: Re: [PATCH net-next v4 0/4] netns: allow to identify peer netns References: <1412257690-31253-1-git-send-email-nicolas.dichtel@6wind.com> <1414682728-4532-1-git-send-email-nicolas.dichtel@6wind.com> <871tpph03k.fsf@x220.int.ebiederm.org> <54535B00.5090708@6wind.com> <87wq7g831b.fsf@x220.int.ebiederm.org> In-Reply-To: <87wq7g831b.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 31/10/2014 20:14, Eric W. Biederman a écrit : > Nicolas Dichtel writes: > >> Le 30/10/2014 19:41, Eric W. Biederman a écrit : >>> Nicolas Dichtel 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 and >>>> http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)). >>>> >>>> Ids of peer netns are set by userland via a new genl messages. These ids are >>>> stored per netns and are local (ie only valid in the netns where they are set). >>>> To avoid allocating an int for each peer netns, I use idr_for_each() to retrieve >>>> the id of a peer netns. Note that it will be possible to add a table (struct net >>>> -> id) later to optimize this lookup if needed. >>>> >>>> Patch 1/4 introduces the netlink API mechanism to set and get these ids. >>>> Patch 2/4 and 3/4 implements an example of how to use these ids in rtnetlink >>>> messages. And patch 4/4 shows that the netlink messages can be symetric between >>>> a GET and a SET. >>>> >>>> iproute2 patches are available, I can send them on demand. >>> >>> A quick reply. I think this patchset is in the right general direction. >>> There are some oddball details that seem odd/awkward to me such as using >>> genetlink instead of rtnetlink to get and set the ids, and not having >>> ids if they are not set (that feels like a maintenance/usability challenge). >> No problem to use rtnetlink, in fact, I hesitated. >> >> For the second point, I'm not sure to follow you: how to have an id, which will >> not break migration, without asking the user to set it? > > We have that situtation with ifindex already. Basically the thought is > to allow an id to be set, but also allow an id to be auto-generated if > we use an namespace without an id being set. If my understanding is correct, the difference is that we want to hide some netns. Do you think we can generate an id for each netns that does not have one and relying on the fact that this id has no meaning unless you have a netns file descriptor that allow you to get the id of this netns? Regards, Nicolas