Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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>
 <a0fe573b-c601-9ffc-1f96-0e5f5da86288@6wind.com>
 <20180124173515.5ae2bc05@redhat.com>
To:     Jiri Benc <jbenc@redhat.com>
Cc:     Christian Brauner <christianvanbrauner@gmail.com>,
        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 <christian.brauner@ubuntu.com>
From:   Nicolas Dichtel <nicolas.dichtel@6wind.com>
Organization: 6WIND
Message-ID: <b8b4a8e3-b574-cc9c-98d1-39911625ad37@6wind.com>
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
Precedence: bulk

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