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.
