Le 18/05/2026 à 15:55, Ilya Maximets a écrit : > 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. Sure, but only for this special path then (ie cross-get). My understanding is that you are interested by the all-nsid-notification path.
> > 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. The problem is changing the netlink API. As you said, a new flag would be needed for this. Regards, Nicolas
