Hi Ilya, 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.
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. I agree the side effects of the self-referential netnsid are unfortunate. But that's an orthogonal problem merely uncovered by IFLA_IF_NETNSID, since, as you correctly note, such netnsid can be created also by other means. This is (AFAICS correctly) fixed by patch 3/5. So, I would argue both the old and the proposed behavior are valid. I agree that from the point of view you're presenting the proposed behavior is easier to use. Double so since you're arguing from the Open vSwitch POV. > 4. A seemingly read-only RTM_GETLINK request for a different namespace > allocates a self-referential nsid for the current namespace, which > is a little unexpected. I, however, don't agree with this argument. RTM_GETLINK has always allocated netnsids, even long before the patch adding IFLA_IF_NETNSID. There's nothing special here. You might call the netnsid allocation unexpected but it's been part of this since the very beginning. > A research across open-source projects doesn't show any projects that > rely on the things that are being changed. I couldn't find any > project that uses the reported LINK_NSID with cross-namespace requests. > And no projects that use cross-namespace requests seem to even parse > the reported LINK_NSID. I trust your research. My main concern would be Open vSwitch breaking with the change; I haven't checked but obviously I trust you there even more. > Of course, that doesn't mean there are no such applications, but the > current behavior feels like a logical bug that IMO should be fixed, > otherwise it's hard to use all-nsid sockets properly. I don't think it's a bug. It's just a different way to look at the interface. I don't have a problem with saying it's more ergonomic and better. I don't have a problem with changing the behavior given your research. But please resend this patch without calling this a bug and without the Fixes: header. Otherwise, it gets a CVE and I don't think that's appropriate here. This is not a stable material, this is a feature adding a behavior change. You'll get my Acked-by then. The real fix for the all-nsid problem is patch 3/5. Thanks! Jiri
