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:   Tue, 23 Jan 2018 10:30:09 +0100
From:   Jiri Benc <jbenc@redhat.com>
To:     Christian Brauner <christian.brauner@canonical.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: <20180123103009.41c2a043@redhat.com>
In-Reply-To: <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>
        <20180122222540.oqrr3apswopavyta@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> 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.

How do you know the interface did not get renamed in the new netns?

This is racy and won't work reliably. You really need to know the
netnsid before moving the interface to the netns to be able to do
meaningful queries.

You may argue that for your case, you're fine with the race. But I know
about use cases where it matters a lot: those are tools that show
network topology including changes in real time, such as Skydive. It's
important to have the uAPI designed right. And we don't want two
different APIs for the same thing.

If you want to do any watching over the interfaces (as opposed to "move
to the netns and forget"), you really have to work with netnsids. Let's
focus on how to do that more easily. We don't return netnsid at all
places where we should return it and we need to fix that.

> There's no non-syscall way to learn the netnsid.

And that is the primary problem.

 Jiri