[PATCH net v2 0/4] netlink: fixes for cross-namespace nsid reporting

While working on some new features for OVS and OVN we discovered that
self-referential NSIDs get unintentionally allocated in the system as
well as unexpectedly reported for local events on all-nsid listeners.

More details in the patches.  They change user-visible behavior, but
the current behavior is arguably a bug, as it makes it hard to use
all-nsid sockets without a decent amount of extra unrelated work of
tracking when new NSIDs are allocated for your local namespace.

Tests are added to check the expected behavior and YNL is extended to
support all-nsid sockets in the tests.


Version 2:
 - The RTM_GETLINK change is dropped for now as it is not suitable for net.
   A fix would require an opt-in flag.  [Jiri, Nicolas]
 - Added a fix for 'nsid_is_set' flag not being reset between sockets. [Sashiko]
 - Refactored the ynl code:
   * Moved recvmsg call into a separate method. [Jakub]
   * Added doc-string for the ntf_listen_all_nsid. [Jakub]
   * Mentioned it in the Notifications API section.

Version 1:
 - https://lore.kernel.org/netdev/20260515201937.2813983-1-i.maximets@ovn.org/


Ilya Maximets (4):
  net: netlink: fix sending unassigned nsid after assigned one
  net: netlink: don't set nsid on local notifications
  tools: ynl: support listening on all nsids
  selftests: net: add a test case for nsid in all nsid notifications

 net/netlink/af_netlink.c                  | 11 ++--
 tools/net/ynl/pyynl/lib/ynl.py            | 37 ++++++++++++--
 tools/testing/selftests/net/link_netns.py | 61 ++++++++++++++++++++++-
 3 files changed, 99 insertions(+), 10 deletions(-)

-- 
2.53.0

If the current skb is not shared, it is re-used directly for all the
sockets subscribed to the notification.  If we have remote all-nsid
socket receiving a message first, then the 'nsid_is_set' will be
set to 'true'.  If the nsid is NOT_ASSIGNED for the next socket in
the list, the 'nsid_is_set' will remain 'true' and the negative value
is be delivered to the user space.  All subsequent nsid values will be
delivered as well, since there is no code path that sets the flag
back to 'false'.

Fix that by always dropping the flag to 'false' first.

Fixes: 7212462fa6fd ("netlink: don't send unknown nsid")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 net/netlink/af_netlink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 2aeb0680807d6..0742e97f256e4 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c

@@ -1482,6 +1482,7 @@ static void do_one_broadcast(struct sock *sk,
 		p->skb2 = NULL;
 		goto out;
 	}
+	NETLINK_CB(p->skb2).nsid_is_set = false;
 	NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net);
 	if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED)
 		NETLINK_CB(p->skb2).nsid_is_set = true;

-- 
2.53.0

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.

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.

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.

Also adding some blank lines for readability.

Fixes: 59324cf35aba ("netlink: allow to listen "all" netns")
Reported-by: Matteo Perin <redacted>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 net/netlink/af_netlink.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0742e97f256e4..7269e23b578d6 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c

@@ -1482,10 +1482,14 @@ static void do_one_broadcast(struct sock *sk,
 		p->skb2 = NULL;
 		goto out;
 	}
+
 	NETLINK_CB(p->skb2).nsid_is_set = false;
-	NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net);
-	if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED)
-		NETLINK_CB(p->skb2).nsid_is_set = true;
+	if (!net_eq(sock_net(sk), p->net)) {
+		NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net);
+		if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED)
+			NETLINK_CB(p->skb2).nsid_is_set = true;
+	}
+
 	val = netlink_broadcast_deliver(sk, p->skb2);
 	if (val < 0) {
 		netlink_overrun(sk);

-- 
2.53.0

A new method ntf_listen_all_nsid() to enable listening on events from
all namespaces.  Useful for testing cross-namespace functionality.

recv() replaced with recvmsg() to be able to receive NSID through the
ancillary data.

Assisted-by: OpenCode:claude-opus-4.6
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 tools/net/ynl/pyynl/lib/ynl.py | 37 +++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
index f63c6f8287359..010aac0c6c67a 100644
--- a/tools/net/ynl/pyynl/lib/ynl.py
+++ b/tools/net/ynl/pyynl/lib/ynl.py

@@ -42,6 +42,7 @@ class Netlink:
     SOL_NETLINK = 270
 
     NETLINK_ADD_MEMBERSHIP = 1
+    NETLINK_LISTEN_ALL_NSID = 8
     NETLINK_CAP_ACK = 10
     NETLINK_EXT_ACK = 11
     NETLINK_GET_STRICT_CHK = 12

@@ -680,6 +681,7 @@ class YnlFamily(SpecFamily):
     Notification API:
 
       ynl.ntf_subscribe(mcast_name)      -- join a multicast group
+      ynl.ntf_listen_all_nsid()          -- listen on all netns
       ynl.check_ntf()                    -- drain pending notifications
       ynl.poll_ntf(duration=None)        -- yield notifications
 

@@ -748,6 +750,23 @@ class YnlFamily(SpecFamily):
         self.sock.setsockopt(Netlink.SOL_NETLINK, Netlink.NETLINK_ADD_MEMBERSHIP,
                              mcast_id)
 
+    def ntf_listen_all_nsid(self):
+        """Enable NETLINK_LISTEN_ALL_NSID to receive notifications from all
+        namespaces that have an nsid mapped in the current one."""
+        self.sock.setsockopt(Netlink.SOL_NETLINK,
+                             Netlink.NETLINK_LISTEN_ALL_NSID, 1)
+
+    @staticmethod
+    def _decode_nsid(ancdata):
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            if (cmsg_level == Netlink.SOL_NETLINK and
+                    cmsg_type == Netlink.NETLINK_LISTEN_ALL_NSID):
+                nsid = struct.unpack('i', cmsg_data)[0]
+                if nsid >= 0:
+                    return nsid
+                return None
+        return None
+
     def set_recv_dbg(self, enabled):
         self._recv_dbg = enabled
 

@@ -1235,7 +1254,7 @@ class YnlFamily(SpecFamily):
                             f" when parsing '{attr_spec['name']}'")
         return raw
 
-    def handle_ntf(self, decoded):
+    def handle_ntf(self, decoded, nsid=None):
         msg = {}
         if self.include_raw:
             msg['raw'] = decoded

@@ -1246,15 +1265,22 @@ class YnlFamily(SpecFamily):
 
         msg['name'] = op['name']
         msg['msg'] = attrs
+        if nsid is not None:
+            msg['nsid'] = nsid
         self.async_msg_queue.put(msg)
 
+    def _recvmsg(self, flags=0):
+        reply, ancdata, _, _ = self.sock.recvmsg(self._recv_size, 4096, flags)
+        return reply, ancdata
+
     def check_ntf(self):
         while True:
             try:
-                reply = self.sock.recv(self._recv_size, socket.MSG_DONTWAIT)
+                reply, ancdata = self._recvmsg(socket.MSG_DONTWAIT)
             except BlockingIOError:
                 return
 
+            nsid = self._decode_nsid(ancdata)
             nms = NlMsgs(reply)
             self._recv_dbg_print(reply, nms)
             for nl_msg in nms:

@@ -1271,7 +1297,7 @@ class YnlFamily(SpecFamily):
                     print("Unexpected msg id while checking for ntf", decoded)
                     continue
 
-                self.handle_ntf(decoded)
+                self.handle_ntf(decoded, nsid)
 
     def poll_ntf(self, duration=None):
         start_time = time.time()

@@ -1335,7 +1361,8 @@ class YnlFamily(SpecFamily):
         rsp = []
         op_rsp = []
         while not done:
-            reply = self.sock.recv(self._recv_size)
+            reply, ancdata = self._recvmsg()
+            nsid = self._decode_nsid(ancdata)
             nms = NlMsgs(reply)
             self._recv_dbg_print(reply, nms)
             for nl_msg in nms:

@@ -1374,7 +1401,7 @@ class YnlFamily(SpecFamily):
                 # Check if this is a reply to our request
                 if nl_msg.nl_seq not in reqs_by_seq or decoded.cmd() != op.rsp_value:
                     if decoded.cmd() in self.async_msg_ids:
-                        self.handle_ntf(decoded)
+                        self.handle_ntf(decoded, nsid)
                         continue
                     print('Unexpected message: ' + repr(decoded))
                     continue

-- 
2.53.0

The test subscribes to link events from all namespaces and makes
sure that local events do not carry NSID in their ancillary data
(even if there is a self-referential NSID allocated for the local
namespace), and remote events do.

Assisted-by: OpenCode:claude-opus-4.6
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 tools/testing/selftests/net/link_netns.py | 61 ++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/net/link_netns.py b/tools/testing/selftests/net/link_netns.py
index aab043c59d695..6d1f863b6262e 100755
--- a/tools/testing/selftests/net/link_netns.py
+++ b/tools/testing/selftests/net/link_netns.py

@@ -3,13 +3,14 @@
 
 import time
 
-from lib.py import ksft_run, ksft_exit, ksft_true
+from lib.py import ksft_run, ksft_exit, ksft_eq, ksft_true
 from lib.py import ip
 from lib.py import NetNS, NetNSEnter
 from lib.py import RtnlFamily
 
 
 LINK_NETNSID = 100
+LINK_NETNSID2 = 200
 
 
 def test_event() -> None:

@@ -32,6 +33,57 @@ def test_event() -> None:
                   "Received unexpected link notification")
 
 
+def test_event_all_nsid() -> None:
+    """NETLINK_LISTEN_ALL_NSID notifications: local events must not
+    carry nsid even with a self-referential mapping.  Remote events
+    must carry the correct nsid."""
+
+    with NetNS() as ns1, NetNS() as ns2:
+        net1, net2 = str(ns1), str(ns2)
+
+        with NetNSEnter(net1):
+            rtnl = RtnlFamily()
+        rtnl.ntf_listen_all_nsid()
+        rtnl.ntf_subscribe("rtnlgrp-link")
+
+        # Case 1: no nsid assigned, local event, no nsid expected.
+        ip("link add dummy-lo type dummy", ns=net1)
+
+        # Case 2: self-referential nsid, local event, still no nsid.
+        ip(f"netns set {net1} {LINK_NETNSID}", ns=net1)
+        ip("link add dummy-sr type dummy", ns=net1)
+
+        # Case 3: remote event, nsid present.
+        ip(f"netns set {net2} {LINK_NETNSID2}", ns=net1)
+        ip("link add dummy-re type dummy", ns=net2)
+
+        # Collect the three newlink events, ignoring unrelated noise.
+        events = {}
+        for msg in rtnl.poll_ntf(duration=1):
+            if msg['name'] == 'getlink':
+                ifname = msg['msg'].get('ifname')
+                if ifname in ('dummy-lo', 'dummy-sr', 'dummy-re'):
+                    events[ifname] = msg
+            if len(events) == 3:
+                break
+
+        ksft_true('dummy-lo' in events, "missing local event")
+        ksft_true(events['dummy-lo'].get('nsid') is None,
+                  "local event without nsid should not carry nsid")
+
+        ksft_true('dummy-sr' in events, "missing self-ref event")
+        ksft_true(events['dummy-sr'].get('nsid') is None,
+                  "local event with self-ref nsid should not carry nsid")
+
+        ksft_true('dummy-re' in events, "missing remote event")
+        ksft_eq(events['dummy-re'].get('nsid'), LINK_NETNSID2,
+                "remote event should carry nsid")
+
+        ip("link del dummy-lo", ns=net1)
+        ip("link del dummy-sr", ns=net1)
+        ip("link del dummy-re", ns=net2)
+
+
 def validate_link_netns(netns, ifname, link_netnsid) -> bool:
     link_info = ip(f"-d link show dev {ifname}", ns=netns, json=True)
     if not link_info:

@@ -133,7 +185,12 @@ def test_peer_net() -> None:
 
 
 def main() -> None:
-    ksft_run([test_event, test_link_net, test_peer_net])
+    ksft_run([
+        test_event,
+        test_event_all_nsid,
+        test_link_net,
+        test_peer_net,
+    ])
     ksft_exit()
 
 

-- 
2.53.0

Le 20/05/2026 à 19:22, Ilya Maximets a écrit :

If the current skb is not shared, it is re-used directly for all the
sockets subscribed to the notification.  If we have remote all-nsid
socket receiving a message first, then the 'nsid_is_set' will be
set to 'true'.  If the nsid is NOT_ASSIGNED for the next socket in
the list, the 'nsid_is_set' will remain 'true' and the negative value
is be delivered to the user space.  All subsequent nsid values will be
delivered as well, since there is no code path that sets the flag
back to 'false'.

Fix that by always dropping the flag to 'false' first.

Fixes: 7212462fa6fd ("netlink: don't send unknown nsid")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Acked-by: Nicolas Dichtel <redacted>

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

On Thu, 21 May 2026 14:36:12 +0200, Nicolas Dichtel wrote:

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.

On the other hand, does the patch break anything in practice (as
opposed to in theory)? It makes live of several apps simpler, which is
not a bad goal.

The only scenario where this would introduce incompatible behavior is
an app that self-assigns a self-nsid and expects to see it. That looks
quite stretched, doesn't it?

Not that I have a strong opinion about this, though.

 Jiri

Le 21/05/2026 à 16:00, Jiri Benc a écrit :

On Thu, 21 May 2026 14:36:12 +0200, Nicolas Dichtel wrote:

quoted

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.

On the other hand, does the patch break anything in practice (as
opposed to in theory)? It makes live of several apps simpler, which is
not a bad goal.

I'm not against the patch, it just look like a workaround.
I'm trying to understand how NETLINK_LISTEN_ALL_NSID is used (in fact, why it is
used if the app doesn't "understand" NSIDs).

The only scenario where this would introduce incompatible behavior is
an app that self-assigns a self-nsid and expects to see it. That looks

Yes, I thought about this.

quite stretched, doesn't it?

It does.

Regards,
Nicolas.

Not that I have a strong opinion about this, though.

 Jiri

On Wed, 20 May 2026 19:22:34 +0200 Ilya Maximets wrote:

Ilya Maximets (4):
  net: netlink: fix sending unassigned nsid after assigned one
  net: netlink: don't set nsid on local notifications
  tools: ynl: support listening on all nsids
  selftests: net: add a test case for nsid in all nsid notifications

Doesn't look like this will make it to today's PR but let me apply
just the ynl change right away, the same code is changed in net-next.
Let me save myself the merge conflict..

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski [off-list ref]:

On Wed, 20 May 2026 19:22:34 +0200 you wrote:

While working on some new features for OVS and OVN we discovered that
self-referential NSIDs get unintentionally allocated in the system as
well as unexpectedly reported for local events on all-nsid listeners.

More details in the patches.  They change user-visible behavior, but
the current behavior is arguably a bug, as it makes it hard to use
all-nsid sockets without a decent amount of extra unrelated work of
tracking when new NSIDs are allocated for your local namespace.

[...]

Here is the summary with links:
  - [net,v2,1/4] net: netlink: fix sending unassigned nsid after assigned one
    (no matching commit)
  - [net,v2,2/4] net: netlink: don't set nsid on local notifications
    (no matching commit)
  - [net,v2,3/4] tools: ynl: support listening on all nsids
    https://git.kernel.org/netdev/net/c/3287e81292f4
  - [net,v2,4/4] selftests: net: add a test case for nsid in all nsid notifications
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

On 5/21/26 4:25 PM, Nicolas Dichtel wrote:

Le 21/05/2026 à 16:00, Jiri Benc a écrit :

quoted

On Thu, 21 May 2026 14:36:12 +0200, Nicolas Dichtel wrote:

quoted

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.

On the other hand, does the patch break anything in practice (as
opposed to in theory)? It makes live of several apps simpler, which is
not a bad goal.

I'm not against the patch, it just look like a workaround.
I'm trying to understand how NETLINK_LISTEN_ALL_NSID is used (in fact, why it is
used if the app doesn't "understand" NSIDs).

ovs-vswitchd works with NSIDs of remote ports.  So it does understand them, it
just doesn't expect the self-referential ones for the local namespace.

openvswitch module has a minimal support for cross-namespace operation.  Ports can
be added to the openvswitch datapath and then moved to a different namespace (it's
a little weird use case, but that's beyond the point here).  ovs-vswitchd learns
new NSIDs of those ports from the openvswitch module and then it can perform a
limited set of cross-namespace operations on them and monitor their status changes
through notifications on an all-nsid socket.  It never learns the NSID of the
current local namespace, because all the local ports can be directly accessed and
openvswitch module doesn't report an NSID for them, as it's not needed for anything.

In the end, ovs-vswitchd knows all the remote NSIDs it needs to know and can
recognize them in notifications.  But it doesn't know the NSID of it's own local
namespace, as the openvswitch module never reports that for local ports and
ovs-vswitchd doesn't explicitly check its own NSID.  So, local notifications with
NSID set get treatment of a notification from some remote namespace that we do not
care about.

We will be putting changes into ovs-vswitch to work around this issue, simply
because it will take time for the kernel patch to propagate to distros.  But this
code will not be useful for anything except for working around this one specific
case and so it would be nice to get rid of it eventually.  And it would be nice
if future applications didn't need to care about this behavior as well.  Having
the fix in stable will speed up the process significantly.

HTH,
Best regards, Ilya Maximets.

Le 21/05/2026 à 18:01, Ilya Maximets a écrit :

On 5/21/26 4:25 PM, Nicolas Dichtel wrote:

quoted

Le 21/05/2026 à 16:00, Jiri Benc a écrit :

quoted

On Thu, 21 May 2026 14:36:12 +0200, Nicolas Dichtel wrote:

quoted

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.

On the other hand, does the patch break anything in practice (as
opposed to in theory)? It makes live of several apps simpler, which is
not a bad goal.

I'm not against the patch, it just look like a workaround.
I'm trying to understand how NETLINK_LISTEN_ALL_NSID is used (in fact, why it is
used if the app doesn't "understand" NSIDs).

ovs-vswitchd works with NSIDs of remote ports.  So it does understand them, it
just doesn't expect the self-referential ones for the local namespace.

openvswitch module has a minimal support for cross-namespace operation.  Ports can
be added to the openvswitch datapath and then moved to a different namespace (it's
a little weird use case, but that's beyond the point here).  ovs-vswitchd learns
new NSIDs of those ports from the openvswitch module and then it can perform a
limited set of cross-namespace operations on them and monitor their status changes
through notifications on an all-nsid socket.  It never learns the NSID of the
current local namespace, because all the local ports can be directly accessed and
openvswitch module doesn't report an NSID for them, as it's not needed for anything.

In the end, ovs-vswitchd knows all the remote NSIDs it needs to know and can
recognize them in notifications.  But it doesn't know the NSID of it's own local
namespace, as the openvswitch module never reports that for local ports and
ovs-vswitchd doesn't explicitly check its own NSID.  So, local notifications with
NSID set get treatment of a notification from some remote namespace that we do not
care about.

We will be putting changes into ovs-vswitch to work around this issue, simply
because it will take time for the kernel patch to propagate to distros.  But this
code will not be useful for anything except for working around this one specific
case and so it would be nice to get rid of it eventually.  And it would be nice
if future applications didn't need to care about this behavior as well.  Having
the fix in stable will speed up the process significantly.

Ok, thanks for the details.

Regards,
Nicolas

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.

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.

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.

Also adding some blank lines for readability.

Fixes: 59324cf35aba ("netlink: allow to listen "all" netns")
Reported-by: Matteo Perin <redacted>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Acked-by: Nicolas Dichtel <redacted>

Le 20/05/2026 à 19:22, Ilya Maximets a écrit :

The test subscribes to link events from all namespaces and makes
sure that local events do not carry NSID in their ancillary data
(even if there is a self-referential NSID allocated for the local
namespace), and remote events do.

Assisted-by: OpenCode:claude-opus-4.6
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Acked-by: Nicolas Dichtel <redacted>

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski [off-list ref]:

On Wed, 20 May 2026 19:22:34 +0200 you wrote:

While working on some new features for OVS and OVN we discovered that
self-referential NSIDs get unintentionally allocated in the system as
well as unexpectedly reported for local events on all-nsid listeners.

More details in the patches.  They change user-visible behavior, but
the current behavior is arguably a bug, as it makes it hard to use
all-nsid sockets without a decent amount of extra unrelated work of
tracking when new NSIDs are allocated for your local namespace.

[...]

Here is the summary with links:
  - [net,v2,1/4] net: netlink: fix sending unassigned nsid after assigned one
    https://git.kernel.org/netdev/net/c/70f8592ee905
  - [net,v2,2/4] net: netlink: don't set nsid on local notifications
    https://git.kernel.org/netdev/net/c/88b126b39f97
  - [net,v2,3/4] tools: ynl: support listening on all nsids
    (no matching commit)
  - [net,v2,4/4] selftests: net: add a test case for nsid in all nsid notifications
    https://git.kernel.org/netdev/net/c/2e43b6424890

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html