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;
Date:   Mon, 22 Jan 2018 23:25:41 +0100
From:   Christian Brauner <christian.brauner@canonical.com>
To:     Jiri Benc <jbenc@redhat.com>
Cc:     Christian Brauner <christian.brauner@ubuntu.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, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, stephen@networkplumber.org
Subject: Re: [PATCH net-next 1/1] rtnetlink: request RTM_GETLINK by pid or fd
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
Content-Disposition: inline
In-Reply-To: <20180122230616.0c457f55@redhat.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

<snip>

> 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