From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Bumiller Subject: Re: [PATCH net-next 1/1] rtnetlink: request RTM_GETLINK by pid or fd Date: Tue, 23 Jan 2018 11:26:58 +0100 Message-ID: <20180123102658.wll4xb7ewjjy5x55@olga.proxmox.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> <20180123103009.41c2a043@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christian Brauner , 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 proxmox-new.maurer-it.com ([212.186.127.180]:42528 "EHLO proxmox-new.maurer-it.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235AbeAWK1B (ORCPT ); Tue, 23 Jan 2018 05:27:01 -0500 Content-Disposition: inline In-Reply-To: <20180123103009.41c2a043@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jan 23, 2018 at 10:30:09AM +0100, Jiri Benc wrote: > 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. Even if you know the netnsid, do the mentioned watches work for nested/child namespaces if eg. a container creates new namespace before and/or after the watch was established and moves interfaces to these child namespaces, would you just see them disappear, or can you keep track of them later on as well? Even if that works, from what the documentation tells me netlink is an unreliable protocol, so if my watcher's socket buffer is full, wouldn't I be losing important tracking information? I think one possible solution to tracking interfaces would be to have a unique identifier that never changes (even if it's just a simple uint64_t incremented whenever an interface is created). But since they're not local to the current namespace that may require a lot of extra permission checks (but I'm just speculating here...). In any case, IFLA_NET_NS_FD/PID are already there and I had been wondering previously why they couldn't be used with RTM_GETLINK, it would just make sense.