On 5/18/26 2:46 PM, Nicolas Dichtel wrote: > Le 18/05/2026 à 14:11, Ilya Maximets a écrit : >> On 5/18/26 8:21 AM, Jiri Benc wrote: >>> Hi Ilya, >> >> Hi, Jiri. Thanks for your thoughts on the matter! >> >>> >>> IIRC this was added because Open vSwitch needed it. I'd expect most >>> users that need to deal with cross-namespace detection to just switch >>> to the given netns prior to issuing RTM_GETLINK; at least, that's what >>> I'm doing in the tools I wrote. >> >> Yeah, that's also what other projects like FRR are doing. It's a bit >> of a hustle for multi-threaded applications, as AFAIK, there is no way >> to just move one thread into a different namespace, so if many threads >> are doing something with the network and you suddenly need to check >> something in a different namespace, you can't really do that without >> pausing all other threads first. But that's a separate thing, unrelated >> to the series. I'm just ranting. :) > Hmm, not sure to understand. setns() is per thread (see man setns()).
Hmm, I got my wires crossed here with something else, I suppose. Though CAP_SYS_ADMIN requirement may be an even higher barrier. > >> >>> >>> On Fri, 15 May 2026 22:19:20 +0200, Ilya Maximets wrote: >>>> But this doesn't work for link nsid in cross-namespace RTM_GETLINK >>>> requests. For some reason the code checks if the original device >>>> and the link are in the same namespace and not if the querier's >>>> namespace is the same as the link's. So the logic becomes: >>>> >>>> - if NSID is not reported, then the link is in the same namespace >>>> as the queried device. >>>> - if NSID is reported, then the link is not in the same namespace >>>> with the queried device. >>> >>> I'm not sure I would call this a bug; the original idea was to use >>> IFLA_IF_NETNSID to switch to the point of view of that netns but >>> without actually switching to that netns. Hence, the netnsid is >>> relative to the caller's netns but otherwise, you get the same reply as >>> you would if you switched to that netns. If you think about it that >>> way, the current reply is consistent. >> >> It makes some sense, but the fact that all-nsid notification and the >> cross-namespace RTM_GETLINK provide different IDs makes it inconsistent >> in my brain. We have: >> >> 1. nsenter(target) + getlink(local) = target-to-link nsid. >> 2. getlink(target) = caller-to-target nsid + caller-to-link nsid. >> 3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid. > > all-nsid-notification appears before cross-getlink. > The goal, for all-nsid-notification, was to be able to receive netlink > messages > of a subset of netns in one socket. So these messages are provided as-is, ie > like if they were sent on a netlink socket opened in the corresponding netns. > It's generic, there is no need to patch every subsystem. > > cross-get*() have been added later. The chosen behavior is friendlier at the > cost of patching every subsystem that is supported. That's exactly my point. If we're creating a special patch for a subsystem, we don't need to adhere to the exact structure of the original message, since the data reported changes anyway. IMO, not reporting nsid that is the same as the caller's nsid is more friendlier. But that's, again, just a difference in opinion at this point, I'll not insist. Best regards, Ilya Maximets.
