Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Nicolas Dichtel]

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()).

> 
>>
>> 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.

[snip]

> 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.
+1

Regards,
Nicolas