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: Thu, 04 Dec 2014 17:21:09 +0100 Message-ID: <548089F5.30202@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> <545A32C4.7070108@6wind.com> 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: <545A32C4.7070108-pdR9zngts4EAvxtiuMwx3w@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 TGUgMDUvMTEvMjAxNCAxNToyMywgTmljb2xhcyBEaWNodGVsIGEgw6ljcml0IDoKPiBMZSAzMS8x MC8yMDE0IDIwOjE0LCBFcmljIFcuIEJpZWRlcm1hbiBhIMOpY3JpdCA6Cj4+IE5pY29sYXMgRGlj aHRlbCA8bmljb2xhcy5kaWNodGVsQDZ3aW5kLmNvbT4gd3JpdGVzOgo+Pgo+Pj4gTGUgMzAvMTAv MjAxNCAxOTo0MSwgRXJpYyBXLiBCaWVkZXJtYW4gYSDDqWNyaXQgOgo+Pj4+IE5pY29sYXMgRGlj aHRlbCA8bmljb2xhcy5kaWNodGVsQDZ3aW5kLmNvbT4gd3JpdGVzOgo+Pj4+Cj4+Pj4+IFRoZSBn b2FsIG9mIHRoaXMgc2VyaWUgaXMgdG8gYmUgYWJsZSB0byBtdWx0aWNhc3QgbmV0bGluayBtZXNz YWdlcyB3aXRoIGFuCj4+Pj4+IGF0dHJpYnV0ZSB0aGF0IGlkZW50aWZ5IGEgcGVlciBuZXRucy4K Pj4+Pj4gVGhpcyBpcyBuZWVkZWQgYnkgdGhlIHVzZXJsYW5kIHRvIGludGVycHJldCBzb21lIGlu Zm9ybWF0aW9ucyBjb250YWluZWQgaW4KPj4+Pj4gbmV0bGluayBtZXNzYWdlcyAobGlrZSBJRkxB X0xJTksgdmFsdWUsIGJ1dCBhbHNvIHNvbWUgb3RoZXIgYXR0cmlidXRlcyBpbiBjYXNlCj4+Pj4+ IG9mIHgtbmV0bnMgbmV0ZGV2aWNlIChzZWUgYWxzbwo+Pj4+PiBodHRwOi8vdGhyZWFkLmdtYW5l Lm9yZy9nbWFuZS5saW51eC5uZXR3b3JrLzMxNTkzMy9mb2N1cz0zMTYwNjQgYW5kCj4+Pj4+IGh0 dHA6Ly90aHJlYWQuZ21hbmUub3JnL2dtYW5lLmxpbnV4Lmtlcm5lbC5jb250YWluZXJzLzI4MzAx L2ZvY3VzPTQyMzkpKS4KPj4+Pj4KPj4+Pj4gSWRzIG9mIHBlZXIgbmV0bnMgYXJlIHNldCBieSB1 c2VybGFuZCB2aWEgYSBuZXcgZ2VubCBtZXNzYWdlcy4gVGhlc2UgaWRzIGFyZQo+Pj4+PiBzdG9y ZWQgcGVyIG5ldG5zIGFuZCBhcmUgbG9jYWwgKGllIG9ubHkgdmFsaWQgaW4gdGhlIG5ldG5zIHdo ZXJlIHRoZXkgYXJlCj4+Pj4+IHNldCkuCj4+Pj4+IFRvIGF2b2lkIGFsbG9jYXRpbmcgYW4gaW50 IGZvciBlYWNoIHBlZXIgbmV0bnMsIEkgdXNlIGlkcl9mb3JfZWFjaCgpIHRvCj4+Pj4+IHJldHJp ZXZlCj4+Pj4+IHRoZSBpZCBvZiBhIHBlZXIgbmV0bnMuIE5vdGUgdGhhdCBpdCB3aWxsIGJlIHBv c3NpYmxlIHRvIGFkZCBhIHRhYmxlCj4+Pj4+IChzdHJ1Y3QgbmV0Cj4+Pj4+IC0+IGlkKSBsYXRl ciB0byBvcHRpbWl6ZSB0aGlzIGxvb2t1cCBpZiBuZWVkZWQuCj4+Pj4+Cj4+Pj4+IFBhdGNoIDEv NCBpbnRyb2R1Y2VzIHRoZSBuZXRsaW5rIEFQSSBtZWNoYW5pc20gdG8gc2V0IGFuZCBnZXQgdGhl c2UgaWRzLgo+Pj4+PiBQYXRjaCAyLzQgYW5kIDMvNCBpbXBsZW1lbnRzIGFuIGV4YW1wbGUgb2Yg aG93IHRvIHVzZSB0aGVzZSBpZHMgaW4gcnRuZXRsaW5rCj4+Pj4+IG1lc3NhZ2VzLiBBbmQgcGF0 Y2ggNC80IHNob3dzIHRoYXQgdGhlIG5ldGxpbmsgbWVzc2FnZXMgY2FuIGJlIHN5bWV0cmljCj4+ Pj4+IGJldHdlZW4KPj4+Pj4gYSBHRVQgYW5kIGEgU0VULgo+Pj4+Pgo+Pj4+PiBpcHJvdXRlMiBw YXRjaGVzIGFyZSBhdmFpbGFibGUsIEkgY2FuIHNlbmQgdGhlbSBvbiBkZW1hbmQuCj4+Pj4KPj4+ PiBBIHF1aWNrIHJlcGx5LiAgSSB0aGluayB0aGlzIHBhdGNoc2V0IGlzIGluIHRoZSByaWdodCBn ZW5lcmFsIGRpcmVjdGlvbi4KPj4+PiBUaGVyZSBhcmUgc29tZSBvZGRiYWxsIGRldGFpbHMgdGhh dCBzZWVtIG9kZC9hd2t3YXJkIHRvIG1lIHN1Y2ggYXMgdXNpbmcKPj4+PiBnZW5ldGxpbmsgaW5z dGVhZCBvZiBydG5ldGxpbmsgdG8gZ2V0IGFuZCBzZXQgdGhlIGlkcywgYW5kIG5vdCBoYXZpbmcK Pj4+PiBpZHMgaWYgdGhleSBhcmUgbm90IHNldCAodGhhdCBmZWVscyBsaWtlIGEgbWFpbnRlbmFu Y2UvdXNhYmlsaXR5IGNoYWxsZW5nZSkuCj4+PiBObyBwcm9ibGVtIHRvIHVzZSBydG5ldGxpbmss IGluIGZhY3QsIEkgaGVzaXRhdGVkLgo+Pj4KPj4+IEZvciB0aGUgc2Vjb25kIHBvaW50LCBJJ20g bm90IHN1cmUgdG8gZm9sbG93IHlvdTogaG93IHRvIGhhdmUgYW4gaWQsIHdoaWNoIHdpbGwKPj4+ IG5vdCBicmVhayBtaWdyYXRpb24sIHdpdGhvdXQgYXNraW5nIHRoZSB1c2VyIHRvIHNldCBpdD8K Pj4KPj4gV2UgaGF2ZSB0aGF0IHNpdHV0YXRpb24gd2l0aCBpZmluZGV4IGFscmVhZHkuICBCYXNp Y2FsbHkgdGhlIHRob3VnaHQgaXMKPj4gdG8gYWxsb3cgYW4gaWQgdG8gYmUgc2V0LCBidXQgYWxz byBhbGxvdyBhbiBpZCB0byBiZSBhdXRvLWdlbmVyYXRlZCBpZgo+PiB3ZSB1c2UgYW4gbmFtZXNw YWNlIHdpdGhvdXQgYW4gaWQgYmVpbmcgc2V0Lgo+IElmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdCwgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB3ZSB3YW50IHRvIGhpZGUgc29tZQo+IG5ldG5z Lgo+IERvIHlvdSB0aGluayB3ZSBjYW4gZ2VuZXJhdGUgYW4gaWQgZm9yIGVhY2ggbmV0bnMgdGhh dCBkb2VzIG5vdCBoYXZlIG9uZSBhbmQKPiByZWx5aW5nIG9uIHRoZSBmYWN0IHRoYXQgdGhpcyBp ZCBoYXMgbm8gbWVhbmluZyB1bmxlc3MgeW91IGhhdmUgYSBuZXRucyBmaWxlCj4gZGVzY3JpcHRv ciB0aGF0IGFsbG93IHlvdSB0byBnZXQgdGhlIGlkIG9mIHRoaXMgbmV0bnM/CkFueSBjb21tZW50 IEVyaWMgPwoKClRoYW5rIHlvdSwKTmljb2xhcwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpDb250YWluZXJzIG1haWxpbmcgbGlzdApDb250YWluZXJzQGxp c3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NvbnRhaW5lcnM= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932570AbaLDQVP (ORCPT ); Thu, 4 Dec 2014 11:21:15 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:36780 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932279AbaLDQVN (ORCPT ); Thu, 4 Dec 2014 11:21:13 -0500 Message-ID: <548089F5.30202@6wind.com> Date: Thu, 04 Dec 2014 17:21:09 +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.3.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> <545A32C4.7070108@6wind.com> In-Reply-To: <545A32C4.7070108@6wind.com> 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 05/11/2014 15:23, Nicolas Dichtel a écrit : > 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? Any comment Eric ? Thank you, Nicolas