On 5/18/26 2:26 PM, Nicolas Dichtel wrote:
> Le 18/05/2026 à 08:21, Jiri Benc a écrit :
>> 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 don't agree. The expected behavior is to have a IFLA_LINK_NETNSID if the 
> link
> part is not in the same netns as the netdev, see d37512a277df ("rtnl: add link
> netns id to interface messages")
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d37512a277df

This patch predates the cross-namespace requests by quite some time,
so I'm not sure it can be used as a source of truth, since the netdev
namespace and the caller's namespace can be interchangeable in the
description.  It's hard to argue about what was the intended behavior
for the scenario that didn't exist at a time.  The semantics decision
had to be made along with the introduction of the cross-namespace
request support.

>>> 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.
> We (6WIND) are using this behavior. It's part of the netlink API.

OK.  Thanks for the info.

The man page for rtnetlink doesn't mention IFLA_LINK_NETNSID at all, so
we don't really have a documented behavior for it.  Which practically
means that the code is the source of truth here, and so be it.  Though
it would be nice to have the man pages updated.

As I said in the other thread, I'll be dropping this one patch for now,
the way forward if necessary would be yet another flag, but it's not
needed at the moment, so no need to further complicate the API.

Best regards, Ilya Maximets.

Reply via email to