From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751692AbeAWQuj (ORCPT ); Tue, 23 Jan 2018 11:50:39 -0500 Received: from mail-wr0-f175.google.com ([209.85.128.175]:38881 "EHLO mail-wr0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbeAWQuh (ORCPT ); Tue, 23 Jan 2018 11:50:37 -0500 X-Google-Smtp-Source: AH8x227/2/FnuCg74Gq9082rWw9+VP83CnIUeCIv2Cdj8CiBcMs+Js2ZgUdA+/31enoKSj0yKYBo/w== Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH net-next 1/1] rtnetlink: request RTM_GETLINK by pid or fd 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> <20180123102658.wll4xb7ewjjy5x55@olga.proxmox.com> To: Wolfgang Bumiller , Jiri Benc 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 From: Nicolas Dichtel Organization: 6WIND Message-ID: <64deff27-258e-3849-f835-ff854478a196@6wind.com> Date: Tue, 23 Jan 2018 17:50:31 +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: <20180123102658.wll4xb7ewjjy5x55@olga.proxmox.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 23/01/2018 à 11:26, Wolfgang Bumiller a écrit : > 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? nsid can be monitored (see ip monitor nsid). > > 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? You can track socket error statistics. In case of error, you can start a dump to ensure that you have the right view of the system. > > 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...). It's not possible to have unique identifiers. With CRIU, you need to be able to reassign all existing ids.