From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Brauner Subject: Re: [PATCH net-next 1/1] rtnetlink: request RTM_GETLINK by pid or fd Date: Mon, 22 Jan 2018 23:25:41 +0100 Message-ID: <20180122222540.oqrr3apswopavyta@gmail.com> References: <20180118202124.21616-1-christian.brauner@ubuntu.com> <20180118202124.21616-2-christian.brauner@ubuntu.com> <20180118212914.74878b82@redhat.com> <20180118205552.jm7shzcojbumax2k@gmail.com> <20180122220046.7b65a98a@redhat.com> <20180122212353.7n6lrruqedfhrwux@gmail.com> <20180122230616.0c457f55@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Christian Brauner , 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, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, stephen@networkplumber.org To: Jiri Benc Return-path: Received: from youngberry.canonical.com ([91.189.89.112]:46117 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbeAVWZp (ORCPT ); Mon, 22 Jan 2018 17:25:45 -0500 Received: from mail-wm0-f71.google.com ([74.125.82.71]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1edkX9-0001Jj-TW for netdev@vger.kernel.org; Mon, 22 Jan 2018 22:25:43 +0000 Received: by mail-wm0-f71.google.com with SMTP id b186so8225509wmf.0 for ; Mon, 22 Jan 2018 14:25:43 -0800 (PST) Content-Disposition: inline In-Reply-To: <20180122230616.0c457f55@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, Jan 22, 2018 at 11:06:16PM +0100, Jiri Benc wrote: > On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote: > > That is certainly a good idea and I'm happy to send a follow-up patch > > for that! > > Note that I haven't looked into that and I don't know whether it is > easily possible. I'll appreciate if you could try that. > > > But there's still value in being able to use > > IFLA_NET_NS_{FD,PID} in scenarios where the network namespace has been > > created by another process. In this case we don't know what its netnsid > > is and not even if it had been assigned one at creation time or not. In > > this case it would be useful to refer to the netns via a pid or fd. A > > more concrete and frequent example is querying a network namespace of a > > (sorry for the buzzword :)) container for all defined network > > interfaces. > > That's what spurred my original comment. If you don't know the netnsid > in such case, we're missing something in uAPI but at a different point > than RTM_GETLINK. > > When you find yourself in a need to query an interface in another > netns, you had to learn about that interface in the first place. > Meaning you got its ifindex (or ifname, perhaps) somehow. My point is, > you should have learned the netnsid at the same time. > different places. If you have a counter example, please speak up. This is not necessarily true in scenarios where I move a network device via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't created. Here is an example: nlmsghdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK; nlmsghdr->nlmsg_type = RTM_NEWLINK; /* move to network namespace of pid */ nla_put_u32(nlmsg, IFLA_NET_NS_PID, pid) /* give interface new name */ nla_put_string(nlmsg, IFLA_IFNAME, ifname) The only thing I have is the pid that identifies the network namespace. There's no non-syscall way to learn the netnsid. In this case I just want to be able to do the analogue to RTM_NEWLINK + IFLA_NET_NS_PID aka RTM_GETLINK + IFLA_NET_NS_PID to e.g. retrieve the list of all network devices in the network namespace identified by pid. Christian