From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751527AbeAYOVI (ORCPT ); Thu, 25 Jan 2018 09:21:08 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:38504 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751429AbeAYOVG (ORCPT ); Thu, 25 Jan 2018 09:21:06 -0500 X-Google-Smtp-Source: AH8x227FhU/OLNHvk+v+44RM4rajLLThj5AU/JXuJzGcNN3j5kkMEXAXjkc9JxYcPSO3wl1GWhD+iA== Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for RTM_{DEL,SET}LINK References: <20180124142634.17766-1-christian.brauner@ubuntu.com> <20180124173515.5ae2bc05@redhat.com> To: Jiri Benc Cc: Christian Brauner , netdev@vger.kernel.org, ebiederm@xmission.com, davem@davemloft.net, dsahern@gmail.com, fw@strlen.de, daniel@iogearbox.net, lucien.xin@gmail.com, mschiffer@universe-factory.net, jakub.kicinski@netronome.com, vyasevich@gmail.com, linux-kernel@vger.kernel.org, w.bumiller@proxmox.com, Christian Brauner From: Nicolas Dichtel Organization: 6WIND Message-ID: Date: Thu, 25 Jan 2018 15:20:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180124173515.5ae2bc05@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 24/01/2018 à 17:35, Jiri Benc a écrit : > On Wed, 24 Jan 2018 16:24:34 +0100, Nicolas Dichtel wrote: >> I wonder if it would be possible to do something in the netlink framework, like >> NETLINK_LISTEN_ALL_NSID. >> Having some ancillary data at the netlink socket level and a function like >> nlsock_net() (instead of sock_net()) to get the corresponding netns. >> With that, it would be possible, in a generci way, to support this feature for >> all netlink family. > > I'm not sure it's worth the effort to do that in the framework. You'll > need modifications all the way down to the code that generates the > attributes anyway. > > It's not enough to just specify that the operation should be done on a > different netns and hide that from the handlers. Take for example the > existing RTM_GETLINK. Let's say it's executed from within ns_a and > targeted to ns_b (thus IFLA_IF_NETNSID = netnsid of ns_b). Now, if > there's a veth interface in ns_b whose other end is in ns_c, there will > be IFLA_LINK_NETNSID attribute in the response. But the value has to be > netnsid of ns_c as seen from *ns_a*. If you just pretended to switch to > ns_b before invoking rtnl_getlink, it would be netnsid of ns_c as seen > from ns_b which would be wrong. Hmm, I don't agree. For me, it would be the correct answer. If user has a socket in ns_a and targets a RTM_GETLINK in ns_b, the answer he gets should be like if it was done in ns_b. This is already the case with messages received with NETLINK_LISTEN_ALL_NSID, there is no reason to do something different. Regards, Nicolas