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. :) > > 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. Where on the left side is what we do and on the right side is what we get in the message. The first case involves the caller-to-target id to enter the namespace, so 1 and 3 work with caller-to-target nsid and the target-to-link nsid, while the cross-namespace call (2) works with the caller-to-target and the caller-to-link nsids. If the cross-namespace call used target-to-link nsid, then the whole thing would be much more consistent as all three types of requests would work with / provide the same data. But since the cross-namespace call works with different data, I'm not sure why it needs to preserve the structure as the other two (i.e. report self-referential id when the link is in the caller's namespace). Though I agree that it's more of a point of view conversation rather than a technical discussion. So we may keep it as-is or add a flag that changes the behavior one way or another, if necessary. > > 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. That's true, the allocation was always there. My point was mostly about allocation of the source-to-source nsid mapping when the request doesn't seemingly require it. But I agree that some allocation is expected. > >> 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. If we don't consider this behavior as a bug than I'd rather just document it and solidify in tests, i.e. drop the code change and update the tests I made in the patch 2/5 to make it clear what is the actual behavior. If we change the logic in the next tree only, it will not be possible for applications to understand what is the behavior without checking the kernel version or introduction of extra flags, i.e. we'd have to make the new behavior opt-in. Which may be fine, I suppose, but will require application changes to take advantage of. For the problem we're facing in OVS, patch 3/5 is indeed enough. I'll split the set in two. I'll send patches 3-5 for net tree after a couple days in case there will be some more comments (beside ones from sashiko). And we can think what to do with the first half of the set in the meantime. Best regards, Ilya Maximets.
