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
