Re: [PATCH net v2 2/4] net: netlink: don't set nsid on local notifications

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 20/05/2026 à 19:22, Ilya Maximets a écrit :
> In most cases, notifications on sockets with NETLINK_LISTEN_ALL_NSID
> do not contain NSID in their ancillary data in case the event is local
> to the listener.
> 
> However, when a self-referential NSID is allocated for a namespace,
> every local notification starts sending this ID to the user space.
> 
> This is problematic, because the listener cannot tell if those
> notifications are local or not anymore without making extra requests
> to figure out if the provided NSID is local or not.  The listener
> can also not figure out the local NSID beforehand as it can be
> allocated at any point in time by other processes, changing the
> structure of the future notifications for everyone.
I don't understand the use of NETLINK_LISTEN_ALL_NSID without being able to
associate an nsid with a netns.

> 
> The value is practically not useful, since it's the namespace's own
> ID that the application has to obtain from other sources in order to
> figure out if it's the same or not.  So, for the application it's
> just an extra busy work with no benefits.  Moreover, applications
> that do not know about this quirk may be mishandling notifications
> with NSID set as notifications from remote namespaces.  This is the
> case for ovs-vswitchd and the iproute2's 'ip monitor' that stops
> printing 'current' and starts printing the nsid number mid-session.
Why does ovs-vswitchd use NETLINK_LISTEN_ALL_NSID if it isn't able to do the
nsis <-> netns association? How are used nl msg with an nsid?

> 
> Lack of clear documentation for this behavior is also not helping.
> 
> A search though open-source projects doesn't reveal any projects
> that use NETNSA_NSID_NOT_ASSIGNED and rely on metadata to contain
> self-referential NSIDs (expected, since the value is not useful).
> Quite the opposite, as already mentioned, there are few applications
> that rely on NSID to not be present in local events.
> 
> Since the value is not useful and actively harmful in some cases,
> let's not report it for local events, making the notifications more
> consistent.
I still don't think that this is the right "fix". The app is broken. Even after
this patch, the bug could be easily triggered again by a third party.
There is nothing wrong with assigning a self-nsid. It would be a lot more robust
for the app to assign itself a self-nsid when it starts.

Regards,
Nicolas