From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dichtel Subject: Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns Date: Thu, 25 Sep 2014 10:53:31 +0200 Message-ID: <5423D80B.9060500@6wind.com> References: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com> <54228D87.3070309@6wind.com> <5422F0F4.6000709@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: 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: Cong Wang Cc: netdev , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andy Lutomirski , Stephen Hemminger , "Eric W. Biederman" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton , David Miller List-Id: containers.vger.kernel.org TGUgMjQvMDkvMjAxNCAxODo0NSwgQ29uZyBXYW5nIGEgw6ljcml0IDoKPiBPbiBXZWQsIFNlcCAy NCwgMjAxNCBhdCA5OjI3IEFNLCBOaWNvbGFzIERpY2h0ZWwKPiA8bmljb2xhcy5kaWNodGVsQDZ3 aW5kLmNvbT4gd3JvdGU6Cj4+IE5vdyBpbmZvcm1hdGlvbnMgZ290IHdpdGggJ2lwIGxpbmsnIGFy ZSB3cm9uZyBhbmQgaW5jb21wbGV0ZToKPj4gICAgLSB0aGUgbGluayBkZXYgaXMgbm93IHR1bmww IGluc3RlYWQgb2YgZXRoMCwgYmVjYXVzZSB3ZSBvbmx5IGdvdCBhbgo+PiBpZmluZGV4Cj4+ICAg ICAgZnJvbSB0aGUga2VybmVsIHdpdGhvdXQgYW55IG5ldG5zIGluZm9ybWF0aW9ucy4KPgo+IFRo aXMgaXMgbm90IG5ldywgbWFjdmxhbiBoYXMgdGhlIHNhbWUgcHJvYmxlbS4gVGhpcyBpcyB3aHkg SSBzYWlkCj4gaXQgaXMgbW9zdGx5IGEgZGlzcGxheSBwcm9ibGVtLCBtYXliZSBqdXN0IG1hcmsg dGhlIGlmaW5kZXggYXMgLTEgb3IKPiBzb21ldGhpbmcgd2hlbiBpdCBpcyBub3QgaW4gdGhpcyBu ZXRucy4gQXQgbGVhc3QgSSBkb24ndCBleHBlY3QgdGhlIGlubmVyCj4gbmV0bnMga25vdyBhbnl0 aGluZyBvdXRzaWRlLCBhbmQgSSBkb24ndCB0aGluayBJIGFtIHRoZSBvbmx5IG9uZSB1c2luZwo+ IG5ldG5zIGluIHRoaXMgd2F5LgpJIHVuZGVyc3RhbmQgeW91ciBwb2ludCBidXQgdGhlcmUgaXMg c2V2ZXJhbCB1c2Ugb2YgbmV0bnMuIE5ldG5zIGNhbiBiZSB1c2VkCmFsc28gdG8gaW5zdGFudGlh dGUgdmlydHVhbCByb3V0ZXJzLiBJbiB0aGlzIGNhc2UsIGFkbWluaXN0cmF0b3JzIG9yIGRhZW1v bnMKbmVlZCB0byBiZSBhYmxlIHRvIG1vbml0b3IgYW5kIGR1bXAgdGhlIGNvbmZpZ3VyYXRpb24g b24gYWxsIG5ldG5zCihwYXJ0aWN1bGFybHkgYmVlaW5nIGFibGUgdG8gaWRlbnRpZnkgZnVsbHkg eC1uZXRucyBpbnRlcmZhY2VzKS4gV2Ugc3RhcnQgdG8KZGlzY3VzcyB0aGlzIGluIG9uZSBvZiB0 aGUgdHdvIHRocmVhZCBwb2ludGVkIGluIG15IGNvdmVyIGxldHRlciBhbmQgZ2V0IHRoZQpjb25j bHVzaW9uIHRoYXQgY2hlY2tpbmcgdXNlciBucyBpcyBhIGdvb2Qgd2F5IHRvIGtub3cgaWYgYW4g aWQgc2hvdWxkIGJlCmRpc2Nsb3NlZCBvciBub3QgZm9yIGEgcGVlciBuZXRucy4KQ2FuIHlvdSBk ZXNjcmliZSB5b3VyIHVzZSBjYXNlPwoKPgo+PiAgICAtIHRoZSBlbmNhcHN1bGF0aW9uIGFkZHJl c3NlcyBhcmUgbm90IHBhcnQgb2YgdGhpcyBuZXRucyBidXQgdGhlIHVzZXIKPj4gZG9lc24ndAo+ PiAgICAgIGtub3duIHRoYXQgKHN0aWxsIGJlY2F1c2UgbmV0bnMgaW5mbyBpcyBtaXNzaW5nKS4g VGhlc2UgSVB2NCBhZGRyZXNzZXMKPj4gbWF5Cj4+ICAgICAgZXhpc3QgaW50byB0aGlzIG5ldG5z Lgo+Cj4gSSBkb24ndCByZW1lbWJlciB5b3VyIHgtbmV0bnMgY29kZSwgYnV0IHdlIGhhdmUgdHdv IGNob2ljZXM6Cj4KPiAxKSBMb29rdXAgdGhlIHJvdXRlIG9mIHRoZSBuZXRucyB3aGljaCBpdCBp cyBpbgo+Cj4gSWYgdGhlIGFkZHJlc3MgaXMgbm90IGF2YWlsYWJsZSBpbiB0aGlzIG5ldG5zLCBp dCB3aWxsIGZhaWwsIHRoaXMgaXMgZXhwZWN0ZWQKPiBzaW5jZSB0dW5uZWwgZGV2aWNlIGlzIG5v dCBhIHB1cmUgTDIgZGV2aWNlLiBPciBtYXliZSBqdXN0IGZhaWwKPiBlYXJseSB3aGVuIHdlIG1v dmUgaXQuCj4KPiAyKSBMb29rdXAgdGhlIHJvdXRlIG9mIHRoZSBuZXRucyB3aGVyZSBpdCB3YXMg Y3JlYXRlZAo+Cj4gVHJhbnNwYXJlbnQgZm9yIHVwcGVyIGxheWVyLCBidXQgYXMgeW91IHNhaWQs IHRoZSBvdXRlciBhZGRyZXNzIGlzIG5vdAo+IGF2YWlsYWJsZSBpbiB0aGlzIG5ldG5zIHRoZXJl Zm9yZSBoYXJkIHRvIGRpc3BsYXkuIEp1c3QgaGlkaW5nIHRoaXMgaW5mb3JtYXRpb24KPiBkb2Vz bid0IHNlZW0gd3JvbmcgdG8gbWUuCllvdXIgYXNzdW1wdGlvbiBoZXJlIGlzIHRoYXQgYWxsIGRh bWVvbnMgd2VyZSBzdGFydGVkIGJlZm9yZSB0aGUgdHVubmVsIHdhcwpjcmVhdGVkLiBCdXQgdGhp cyBpcyBub3QgdHJ1ZSwgYSBkYWVtb24gbWF5IGJlIHN0YXJ0ZWQgbGF0ZXIuIEFub3RoZXIgY2Fz ZSBpcwp3aGVuIGEgZGFlbW9uIGNyYXNoOiB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gcmVzdGFydCBp dCBhbmQgaXQgc2hvdWxkIGJlIGFibGUgdG8KcmVjb3ZlciBhbGwgbmVlZGVkIGluZm9ybWF0aW9u LgoKPgo+Cj4+ICAgIC0gaXQncyBub3QgcG9zc2libGUgdG8gY3JlYXRlIHRoZSBzYW1lIG5ldGRl dmljZSB3aXRoIHRoZXNlIGluZm9zLgo+Pgo+Cj4gVGhpcyBpcyBleHBlY3RlZCwgYmVjYXVzZSBh ZnRlciBhbGwgeW91IGFyZSBhbHJlYWR5IGluIGEgZGlmZmVyZW50IG5ldG5zLgo+CkEgZGlmZmVy ZW50IG5ldG5zIG9ubHkgbWVhbnMgYSBkaWZmZXJlbnQgbmV0d29yayBzdGFjaywgbm90IGEgZGlm ZmVyZW50IHVzZXIgbnMKb3IgbW91bnQgbnMgb3IgUElEIG5zLCAuLi4KSWYgeW91IG9ubHkgcGxh eSB3aXRoIG5ldG5zLCB5b3UgbWF5IHdhbnQgdG8gbW9uaXRvciBhbGwgYWN0aXZpZXMgaW4gYWxs IG5ldG5zCih0aGlzIGlzIGFscmVhZHkgcG9zc2libGUpIGFuZCBiZWVpbmcgYWJsZSB0byBsaW5r IGluZm9ybWF0aW9uIGJldHdlZW4gbmV0bnMKKHRoaXMgaXMgd2hhdCBJJ20gdHJ5aW5nIHRvIHNv bHZlKS4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29u dGFpbmVycyBtYWlsaW5nIGxpc3QKQ29udGFpbmVyc0BsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9y ZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb250 YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752739AbaIYIxm (ORCPT ); Thu, 25 Sep 2014 04:53:42 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:58345 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbaIYIxe (ORCPT ); Thu, 25 Sep 2014 04:53:34 -0400 Message-ID: <5423D80B.9060500@6wind.com> Date: Thu, 25 Sep 2014 10:53:31 +0200 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.1.1 MIME-Version: 1.0 To: Cong Wang CC: netdev , containers@lists.linux-foundation.org, "linux-kernel@vger.kernel.org" , linux-api@vger.kernel.org, David Miller , "Eric W. Biederman" , Stephen Hemminger , Andrew Morton , Andy Lutomirski Subject: Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns References: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com> <54228D87.3070309@6wind.com> <5422F0F4.6000709@6wind.com> In-Reply-To: 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 24/09/2014 18:45, Cong Wang a écrit : > On Wed, Sep 24, 2014 at 9:27 AM, Nicolas Dichtel > wrote: >> Now informations got with 'ip link' are wrong and incomplete: >> - the link dev is now tunl0 instead of eth0, because we only got an >> ifindex >> from the kernel without any netns informations. > > This is not new, macvlan has the same problem. This is why I said > it is mostly a display problem, maybe just mark the ifindex as -1 or > something when it is not in this netns. At least I don't expect the inner > netns know anything outside, and I don't think I am the only one using > netns in this way. I understand your point but there is several use of netns. Netns can be used also to instantiate virtual routers. In this case, administrators or daemons need to be able to monitor and dump the configuration on all netns (particularly beeing able to identify fully x-netns interfaces). We start to discuss this in one of the two thread pointed in my cover letter and get the conclusion that checking user ns is a good way to know if an id should be disclosed or not for a peer netns. Can you describe your use case? > >> - the encapsulation addresses are not part of this netns but the user >> doesn't >> known that (still because netns info is missing). These IPv4 addresses >> may >> exist into this netns. > > I don't remember your x-netns code, but we have two choices: > > 1) Lookup the route of the netns which it is in > > If the address is not available in this netns, it will fail, this is expected > since tunnel device is not a pure L2 device. Or maybe just fail > early when we move it. > > 2) Lookup the route of the netns where it was created > > Transparent for upper layer, but as you said, the outer address is not > available in this netns therefore hard to display. Just hiding this information > doesn't seem wrong to me. Your assumption here is that all dameons were started before the tunnel was created. But this is not true, a daemon may be started later. Another case is when a daemon crash: we need to be able to restart it and it should be able to recover all needed information. > > >> - it's not possible to create the same netdevice with these infos. >> > > This is expected, because after all you are already in a different netns. > A different netns only means a different network stack, not a different user ns or mount ns or PID ns, ... If you only play with netns, you may want to monitor all activies in all netns (this is already possible) and beeing able to link information between netns (this is what I'm trying to solve).