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

[Nicolas Dichtel]

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