On Wed, 27 May 2026 at 00:35, Ilya Maximets <[email protected]> wrote:
> On 3/18/26 12:04 PM, Matteo Perin via dev wrote: > > When NETLINK_LISTEN_ALL_NSID is enabled on the RTNL notification > > socket, the kernel tags every broadcast RTM event with the sender > > nsid as looked up in the receiver namespace-id table. Normally, > > events originating in the local namespace carry no nsid cmsg (which > > OVS interprets as NETNSID_LOCAL). > > > > However, some container runtimes cause the kernel to create a > > self-referential nsid mapping (the root namespace gets a real nsid > > that points back to itself) as a side-effect of cross namespace > > link queries (RTM_GETLINK). When this mapping exists, the kernel > > tags locally-originated events with that nsid instead of omitting > > the cmsg, causing OVS to silently reject them. > > The reporting was fixed upstream: > https://git.kernel.org/netdev/net/c/88b126b39f97 > But ew still need a solution for older kernels in one form or another. Thank you Ilya for the review and I apologize for the late response. Great news on the patch being approved approved and merged upstream! Since we still need the workaround for older kernels, as you said, I will be sending a revised version of the patchset shortly. The whole set looks fine to me, but I'd change the approach for this > particular patch a bit. See below. > > > > > Fix this by: > > > > - At startup, query the kernel (RTM_GETNSID on /proc/self/ns/net) > > to discover whether a self-referential nsid mapping already exists. > > I'd suggest to avoid relying on procfs. Using a pid might be a better > solution here. Yes, procfs is overkill here in hindsight, I will change the code to rely on the PID to discover the nsid mapping. > > > - Subscribe the notification socket to RTNLGRP_NSID so that > > RTM_NEWNSID events are received whenever the kernel creates a new > > nsid mapping. On receiving such a notification, immediately > > re-query the self-nsid. This is race-free: the notification and > > the first tagged event arrive on the same socket and are processed > > sequentially, so the self-nsid is updated before any tagged event > > is evaluated. > > > > - In netdev_linux_update(), treat the self-nsid as equivalent to > > NETNSID_LOCAL for local devices. Remote devices retain strict > > nsid matching via the vport-queried nsid. > > Instead of subscribing and re-adjusting things in runtime, I'd suggest > we simply create a self-referential nsid for ourselves at the startup > or get it if it is already available. Then just use that value as local, > along with -1 and the non-provided nsid. > > The nsid can't change once set, so we will not need to monitor any extra > events in this case. > > We could create lib/netnsid.c with a global variable that we could set > from netdev-linux before creating the sockets and make netnsid_is_local() > check that variable as well. I did not go with this route since I was a little wary about changing the underlying nsid mapping on the fly, but by following the discussion on the kernel patch submission you made and your points here I can see the value in having a more "static" setup and saving us the need to monitor new events. I will make some last adjustments and send v6 before the end of the day. Best Regards, Matteo _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
