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

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

[Ilya Maximets]

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.

Ilya Maximets (5):
  net: rtnetlink: fix link nsid reported when the link is local
  selftests: net: add a test case for cross-namespace peer netns
  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/core/rtnetlink.c                      |   2 +-
 net/netlink/af_netlink.c                  |   8 +-
 tools/net/ynl/pyynl/lib/ynl.py            |  32 +++++--
 tools/testing/selftests/net/link_netns.py | 101 +++++++++++++++++++++-
 4 files changed, 132 insertions(+), 11 deletions(-)

-- 
2.53.0

[PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Ilya Maximets]

For most netlink replies and notifications the expected behavior is:

- if NSID is not reported, then the device is local to the querier.
- if NSID is reported, then the device is remote, i.e., located in
  the provided namespace that is not the same as the querier's.

Userspace applications like ovs-vswitchd expect this behavior.  And
ip monitor uses this logic for printing out [nsid current] vs [nsid N].

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.

If the link is in the same namespace as the querier, the code will
allocate a self-referential nsid for the querier's namespace and
report it as a link nsid.  This is problematic because:

1. Application doesn't expect to see nsid reported for its own
   namespace.

2. Application can't know if this nsid is the nsid of the current
   namespace without making extra requests.  So a lot of extra
   logic is needed to understand if the link is local or not.

3. Implicit allocation of self-referential nsid for the current
   namespace affects notifications on sockets listening on all
   namespaces, since this nsid is now reported in every notification.
   And so those notification handlers also now need extra logic to
   understand which namespace the events are coming from.

4. A seemingly read-only RTM_GETLINK request for a different namespace
   allocates a self-referential nsid for the current namespace, which
   is a little unexpected.

Let's fix that by applying the same rules to cross-namespace requests
as for standard ones, which is:

- Report NSID if it is different from the querier's namespace.

This changes two things:

1. If both the device and the link are in the same namespace which
   is not the querier's namespace, the LINK_NSID will now be reported.
   This just gives more info and the user can check if the reported
   id is the same as TARGET_NSID, which is in the same message.

2. If the link is in the same namespace as the querier, but the
   device isn't, the LINK_NSID will no longer be reported.
   This is the main change, as previously this would mean that the
   link is in the TARGET namespace, but now it will mean that the
   link is in the SOURCE namespace.

There are no changes in logic for queries that are not cross-namespace
queries.

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.

Of course, that doesn't mean there are no such applications, but the
current behavior feels like a logical bug that IMO should be fixed,
otherwise it's hard to use all-nsid sockets properly.

Note that the logic for notifications in rtmsg_ifinfo_build_skb()
remains the same as those are formatted from the perspective of the
namespace where event occurred, i.e., they are always "local", but
then distributed to sockets listening on all NSIDs with extra metadata
pointing out the original namespace.  And users need to translate
the reported NSIDs to their reference point.  While RTM_GETLINK
always reports NSID from the querier's reference point.  Hence the
reason it should not be reported if it is the same.

Fixes: 79e1ad148c84 ("rtnetlink: use netnsid to query interface")
Reported-by: Matteo Perin <matteo.perin@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 net/core/rtnetlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index df042da422ef3..0d539b8e4bf61 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1881,7 +1881,7 @@ static int rtnl_fill_link_netnsid(struct sk_buff *skb,
 	if (dev->rtnl_link_ops && dev->rtnl_link_ops->get_link_net) {
 		struct net *link_net = dev->rtnl_link_ops->get_link_net(dev);
 
-		if (!net_eq(dev_net(dev), link_net)) {
+		if (!net_eq(src_net, link_net)) {
 			int id = peernet2id_alloc(src_net, link_net, gfp);
 
 			if (nla_put_s32(skb, IFLA_LINK_NETNSID, id))
-- 
2.53.0

[PATCH net 2/5] selftests: net: add a test case for cross-namespace peer netns

[Ilya Maximets]

The test makes requests with RTM_GETLINK and TARGET_NETNS and verifies
that reported LINK_NSID is correct and only reported when it is needed
from the querier's perspective.

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

diff --git a/tools/testing/selftests/net/link_netns.py b/tools/testing/selftests/net/link_netns.py
index aab043c59d695..2aae422d3f8a6 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:
@@ -132,8 +133,52 @@ def test_peer_net() -> None:
                 ip(f"link del foo", ns=tgt_net)
 
 
+def test_peer_net_cross_ns() -> None:
+    """Cross-namespace RTM_GETLINK queries using target-netnsid.
+    IFLA_LINK_NETNSID should report the link peer's namespace from the
+    querier's perspective.  Absent means the peer is in the querier's
+    own namespace.  Must not create self-referential nsid mappings."""
+
+    with NetNS() as ns1, NetNS() as ns2, NetNS() as ns3:
+        net1, net2, net3 = str(ns1), str(ns2), str(ns3)
+
+        ip(f"netns set {net2} {LINK_NETNSID}", ns=net1)
+        ip(f"netns set {net3} {LINK_NETNSID2}", ns=net1)
+
+        with NetNSEnter(net1):
+            rtnl = RtnlFamily()
+
+        cases = [
+            # "dev netns", "peer netns", "query nsid", expected link-netnsid.
+            (net2, net1, LINK_NETNSID, None),
+            (net2, net2, LINK_NETNSID, LINK_NETNSID),
+            (net2, net3, LINK_NETNSID, LINK_NETNSID2),
+        ]
+
+        for dev_ns, peer_ns, query_nsid, exp in cases:
+            ip(f"link add foo netns {dev_ns} type veth"
+               f" peer name bar netns {peer_ns}")
+
+            resp = rtnl.getlink({"target-netnsid": query_nsid,
+                                 "ifname": "foo"})
+            ksft_eq(resp.get("link-netnsid"), exp,
+                    f"link-netnsid mismatch for dev={dev_ns} peer={peer_ns}")
+
+            ip("link del foo", ns=dev_ns)
+
+        # Verify no extra nsid was created by the queries.
+        nsids = ip("netns list-id", ns=net1, json=True)
+        ksft_eq(len(nsids), 2,
+                f"unexpected nsid mappings after cross-ns queries: {nsids}")
+
+
 def main() -> None:
-    ksft_run([test_event, test_link_net, test_peer_net])
+    ksft_run([
+        test_event,
+        test_link_net,
+        test_peer_net,
+        test_peer_net_cross_ns,
+    ])
     ksft_exit()
 
 
-- 
2.53.0

[PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Ilya Maximets]

For notifications with NETLINK_LISTEN_ALL_NSID the expected behavior
is the following:

- if NSID is not reported, then the event is local to the listener.
- if NSID is reported, then the event is remote, i.e., originated in
  the provided namespace that is not the same as the listener's.

Userspace applications like ovs-vswitchd expect this behavior.  And
ip monitor uses this logic for printing out [nsid current] vs [nsid N].

However, when a self-referential NSID is allocated for a namespace,
every local notification starts sending this ID to userspace as part
of NETLINK_LISTEN_ALL_NSID CMSG metadata.

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.

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 while they
are actually local.  This is the case with ovs-vswitchd.

Having a self-referential NSID mapping is not something that happens
under normal circumstances, but it can be a case in specific
environments.  And it can be more common with certain container
runtimes like LXC/LXD/Incus that unintentionally trigger allocation
of the self-referential NSID via cross-namespace RTM_GETLINK requests.

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.  Quite the opposite, ovs-vswitchd relies
on the metadata to not be present to separate local and remote
events.  And the 'ip monitor' relies on the metadata to not be present
to show '[nsid current]', though this is more like "print 'current'
if there is nothing to print" situation, but still can be a little
confusing for the user to see an ID for a local event.

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

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 2aeb0680807d6..607ab4e4ac697 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1482,9 +1482,11 @@ static void do_one_broadcast(struct sock *sk,
 		p->skb2 = NULL;
 		goto out;
 	}
-	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

[PATCH net 4/5] tools: ynl: support listening on all nsids

[Ilya Maximets]

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 | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
index f63c6f8287359..6d96c2b06507e 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
@@ -748,6 +749,21 @@ class YnlFamily(SpecFamily):
         self.sock.setsockopt(Netlink.SOL_NETLINK, Netlink.NETLINK_ADD_MEMBERSHIP,
                              mcast_id)
 
+    def ntf_listen_all_nsid(self):
+        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 +1251,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 +1262,20 @@ 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 check_ntf(self):
         while True:
             try:
-                reply = self.sock.recv(self._recv_size, socket.MSG_DONTWAIT)
+                reply, ancdata, _, _ = self.sock.recvmsg(self._recv_size,
+                                                         4096,
+                                                         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 +1292,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 +1356,8 @@ class YnlFamily(SpecFamily):
         rsp = []
         op_rsp = []
         while not done:
-            reply = self.sock.recv(self._recv_size)
+            reply, ancdata, _, _ = self.sock.recvmsg(self._recv_size, 4096)
+            nsid = self._decode_nsid(ancdata)
             nms = NlMsgs(reply)
             self._recv_dbg_print(reply, nms)
             for nl_msg in nms:
@@ -1374,7 +1396,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

[PATCH net 5/5] selftests: net: add a test case for nsid in all nsid notifications

[Ilya Maximets]

The test makes 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 | 52 +++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/tools/testing/selftests/net/link_netns.py b/tools/testing/selftests/net/link_netns.py
index 2aae422d3f8a6..1e766154cb573 100755
--- a/tools/testing/selftests/net/link_netns.py
+++ b/tools/testing/selftests/net/link_netns.py
@@ -33,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:
@@ -175,6 +226,7 @@ def test_peer_net_cross_ns() -> None:
 def main() -> None:
     ksft_run([
         test_event,
+        test_event_all_nsid,
         test_link_net,
         test_peer_net,
         test_peer_net_cross_ns,
-- 
2.53.0

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Jiri Benc]

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'm not sure I would call this a bug; the original idea was to use
IFLA_IF_NETNSID to switch to the point of view of that netns but
without actually switching to that netns. Hence, the netnsid is
relative to the caller's netns but otherwise, you get the same reply as
you would if you switched to that netns. If you think about it that
way, the current reply is consistent.

I agree the side effects of the self-referential netnsid are
unfortunate. But that's an orthogonal problem merely uncovered by
IFLA_IF_NETNSID, since, as you correctly note, such netnsid can be
created also by other means. This is (AFAICS correctly) fixed by patch
3/5.

So, I would argue both the old and the proposed behavior are valid.
I agree that from the point of view you're presenting the proposed
behavior is easier to use. Double so since you're arguing from the Open
vSwitch POV.

> 4. A seemingly read-only RTM_GETLINK request for a different namespace
>    allocates a self-referential nsid for the current namespace, which
>    is a little unexpected.

I, however, don't agree with this argument. RTM_GETLINK has always
allocated netnsids, even long before the patch adding IFLA_IF_NETNSID.
There's nothing special here. You might call the netnsid allocation
unexpected but it's been part of this since the very beginning.

> 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.

I trust your research. My main concern would be Open vSwitch breaking
with the change; I haven't checked but obviously I trust you there even
more.

> Of course, that doesn't mean there are no such applications, but the
> current behavior feels like a logical bug that IMO should be fixed,
> otherwise it's hard to use all-nsid sockets properly.

I don't think it's a bug. It's just a different way to look at the
interface. I don't have a problem with saying it's more ergonomic and
better. I don't have a problem with changing the behavior given your
research. But please resend this patch without calling this a bug and
without the Fixes: header. Otherwise, it gets a CVE and I don't think
that's appropriate here. This is not a stable material, this is a
feature adding a behavior change. You'll get my Acked-by then.

The real fix for the all-nsid problem is patch 3/5.

Thanks!

 Jiri

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Ilya Maximets]

On 5/18/26 8:21 AM, Jiri Benc wrote:
> Hi Ilya,

Hi, Jiri.  Thanks for your thoughts on the matter!

> 
> 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.

Yeah, that's also what other projects like FRR are doing.  It's a bit
of a hustle for multi-threaded applications, as AFAIK, there is no way
to just move one thread into a different namespace, so if many threads
are doing something with the network and you suddenly need to check
something in a different namespace, you can't really do that without
pausing all other threads first.  But that's a separate thing, unrelated
to the series.  I'm just ranting. :) 

> 
> 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'm not sure I would call this a bug; the original idea was to use
> IFLA_IF_NETNSID to switch to the point of view of that netns but
> without actually switching to that netns. Hence, the netnsid is
> relative to the caller's netns but otherwise, you get the same reply as
> you would if you switched to that netns. If you think about it that
> way, the current reply is consistent.

It makes some sense, but the fact that all-nsid notification and the
cross-namespace RTM_GETLINK provide different IDs makes it inconsistent
in my brain.  We have:

1. nsenter(target) + getlink(local) = target-to-link nsid.
2. getlink(target) = caller-to-target nsid  + caller-to-link nsid.
3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid.

Where on the left side is what we do and on the right side is what we
get in the message.  The first case involves the caller-to-target id
to enter the namespace, so 1 and 3 work with caller-to-target nsid
and the target-to-link nsid, while the cross-namespace call (2) works
with the caller-to-target and the caller-to-link nsids.

If the cross-namespace call used target-to-link nsid, then the whole
thing would be much more consistent as all three types of requests would
work with / provide the same data.  But since the cross-namespace call
works with different data, I'm not sure why it needs to preserve the
structure as the other two (i.e. report self-referential id when the
link is in the caller's namespace).  Though I agree that it's more of a
point of view conversation rather than a technical discussion.  So we
may keep it as-is or add a flag that changes the behavior one way or
another, if necessary.

> 
> I agree the side effects of the self-referential netnsid are
> unfortunate. But that's an orthogonal problem merely uncovered by
> IFLA_IF_NETNSID, since, as you correctly note, such netnsid can be
> created also by other means. This is (AFAICS correctly) fixed by patch
> 3/5.
> 
> So, I would argue both the old and the proposed behavior are valid.
> I agree that from the point of view you're presenting the proposed
> behavior is easier to use. Double so since you're arguing from the Open
> vSwitch POV.
> 
>> 4. A seemingly read-only RTM_GETLINK request for a different namespace
>>    allocates a self-referential nsid for the current namespace, which
>>    is a little unexpected.
> 
> I, however, don't agree with this argument. RTM_GETLINK has always
> allocated netnsids, even long before the patch adding IFLA_IF_NETNSID.
> There's nothing special here. You might call the netnsid allocation
> unexpected but it's been part of this since the very beginning.

That's true, the allocation was always there.  My point was mostly about
allocation of the source-to-source nsid mapping when the request doesn't
seemingly require it.  But I agree that some allocation is expected.

> 
>> 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.
> 
> I trust your research. My main concern would be Open vSwitch breaking
> with the change; I haven't checked but obviously I trust you there even
> more.
> 
>> Of course, that doesn't mean there are no such applications, but the
>> current behavior feels like a logical bug that IMO should be fixed,
>> otherwise it's hard to use all-nsid sockets properly.
> 
> I don't think it's a bug. It's just a different way to look at the
> interface. I don't have a problem with saying it's more ergonomic and
> better. I don't have a problem with changing the behavior given your
> research. But please resend this patch without calling this a bug and
> without the Fixes: header. Otherwise, it gets a CVE and I don't think
> that's appropriate here. This is not a stable material, this is a
> feature adding a behavior change. You'll get my Acked-by then.
> 
> The real fix for the all-nsid problem is patch 3/5.

If we don't consider this behavior as a bug than I'd rather just document
it and solidify in tests, i.e. drop the code change and update the tests
I made in the patch 2/5 to make it clear what is the actual behavior.
If we change the logic in the next tree only, it will not be possible for
applications to understand what is the behavior without checking the
kernel version or introduction of extra flags, i.e. we'd have to make the
new behavior opt-in.  Which may be fine, I suppose, but will require
application changes to take advantage of.

For the problem we're facing in OVS, patch 3/5 is indeed enough.  I'll
split the set in two.  I'll send patches 3-5 for net tree  after a couple
days in case there will be some more comments (beside ones from sashiko).
And we can think what to do with the first half of the set in the meantime.

Best regards, Ilya Maximets.

Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Nicolas Dichtel]

Le 15/05/2026 à 22:19, Ilya Maximets a écrit :
> For notifications with NETLINK_LISTEN_ALL_NSID the expected behavior
> is the following:
> 
> - if NSID is not reported, then the event is local to the listener.
> - if NSID is reported, then the event is remote, i.e., originated in
>   the provided namespace that is not the same as the listener's.
> 
> Userspace applications like ovs-vswitchd expect this behavior.  And
> ip monitor uses this logic for printing out [nsid current] vs [nsid N].
> 
> However, when a self-referential NSID is allocated for a namespace,
> every local notification starts sending this ID to userspace as part
> of NETLINK_LISTEN_ALL_NSID CMSG metadata.
> 
> 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.
> 
> 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 while they
> are actually local.  This is the case with ovs-vswitchd.
> 
> Having a self-referential NSID mapping is not something that happens
> under normal circumstances, but it can be a case in specific
> environments.  And it can be more common with certain container
> runtimes like LXC/LXD/Incus that unintentionally trigger allocation
> of the self-referential NSID via cross-namespace RTM_GETLINK requests.
It is easy to allocate a self-nsid:
$ ip netns attach current $$
$ ip netns set current auto
$ ip netns list-id
nsid 0 (iproute2 netns name: current)

An application should be prepared to handle this (it is easy for an app to get
the 'self-nsid' value).

> 
> 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.  Quite the opposite, ovs-vswitchd relies
> on the metadata to not be present to separate local and remote
> events.  And the 'ip monitor' relies on the metadata to not be present
> to show '[nsid current]', though this is more like "print 'current'
> if there is nothing to print" situation, but still can be a little
> confusing for the user to see an ID for a local event.

We (6WIND) are using NETLINK_LISTEN_ALL_NSID. Like iproute2, 'current' is
assumed if there is no nsid, else the corresponding netns is checked (which may
match the current netns).

> 
> Fixes: 59324cf35aba ("netlink: allow to listen "all" netns")
> Reported-by: Matteo Perin <matteo.perin@canonical.com>
> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
> ---
>  net/netlink/af_netlink.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 2aeb0680807d6..607ab4e4ac697 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1482,9 +1482,11 @@ static void do_one_broadcast(struct sock *sk,
>  		p->skb2 = NULL;
>  		goto out;
>  	}
> -	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);

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Nicolas Dichtel]

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

> 
> I'm not sure I would call this a bug; the original idea was to use
> IFLA_IF_NETNSID to switch to the point of view of that netns but
> without actually switching to that netns. Hence, the netnsid is
> relative to the caller's netns but otherwise, you get the same reply as
> you would if you switched to that netns. If you think about it that
> way, the current reply is consistent.
+1

> 
> I agree the side effects of the self-referential netnsid are
> unfortunate. But that's an orthogonal problem merely uncovered by
> IFLA_IF_NETNSID, since, as you correctly note, such netnsid can be
> created also by other means. This is (AFAICS correctly) fixed by patch
> 3/5.
As said in my other reply, getting the self-nsid of a netns isn't complex. An
application should be prepared to handle this.

> 
> So, I would argue both the old and the proposed behavior are valid.
> I agree that from the point of view you're presenting the proposed
> behavior is easier to use. Double so since you're arguing from the Open
> vSwitch POV.
> 
>> 4. A seemingly read-only RTM_GETLINK request for a different namespace
>>    allocates a self-referential nsid for the current namespace, which
>>    is a little unexpected.
> 
> I, however, don't agree with this argument. RTM_GETLINK has always
> allocated netnsids, even long before the patch adding IFLA_IF_NETNSID.
> There's nothing special here. You might call the netnsid allocation
> unexpected but it's been part of this since the very beginning.
+1

> 
>> 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.

Regards,
Nicolas

Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Ilya Maximets]

On 5/18/26 2:14 PM, Nicolas Dichtel wrote:
> Le 15/05/2026 à 22:19, Ilya Maximets a écrit :
>> For notifications with NETLINK_LISTEN_ALL_NSID the expected behavior
>> is the following:
>>
>> - if NSID is not reported, then the event is local to the listener.
>> - if NSID is reported, then the event is remote, i.e., originated in
>>   the provided namespace that is not the same as the listener's.
>>
>> Userspace applications like ovs-vswitchd expect this behavior.  And
>> ip monitor uses this logic for printing out [nsid current] vs [nsid N].
>>
>> However, when a self-referential NSID is allocated for a namespace,
>> every local notification starts sending this ID to userspace as part
>> of NETLINK_LISTEN_ALL_NSID CMSG metadata.
>>
>> 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.
>>
>> 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 while they
>> are actually local.  This is the case with ovs-vswitchd.
>>
>> Having a self-referential NSID mapping is not something that happens
>> under normal circumstances, but it can be a case in specific
>> environments.  And it can be more common with certain container
>> runtimes like LXC/LXD/Incus that unintentionally trigger allocation
>> of the self-referential NSID via cross-namespace RTM_GETLINK requests.
> It is easy to allocate a self-nsid:
> $ ip netns attach current $$
> $ ip netns set current auto
> $ ip netns list-id
> nsid 0 (iproute2 netns name: current)

That's true.  My point was that it's not something that most people do often.
Though it can surely be common on some setups.

> An application should be prepared to handle this

Yeah.  Unfortunately, documentation is not clear on when the nsid is
provided and when it isn't, so some applications do not currently handle
the self-referential case.

> (it is easy for an app to get the 'self-nsid' value).

True and also not really.  The main problem is that ID can be allocated
at any point in time, so the application needs to listen for NEW messages
on the same socket that it is listening for the events that are interesting
to it (to avoid races), if it doesn't want to make a separate GET request
per notification or track all the IDs that were previously checked.  It's a
non-trivial amount of code depending on the application structure.

Alternative is to always try and allocate the self-referential mapping on
the application startup and remember it, and then check that no-id, -1 and
the allocated one all mean 'current'.

> 
>>
>> 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.  Quite the opposite, ovs-vswitchd relies
>> on the metadata to not be present to separate local and remote
>> events.  And the 'ip monitor' relies on the metadata to not be present
>> to show '[nsid current]', though this is more like "print 'current'
>> if there is nothing to print" situation, but still can be a little
>> confusing for the user to see an ID for a local event.
> 
> We (6WIND) are using NETLINK_LISTEN_ALL_NSID. Like iproute2, 'current' is
> assumed if there is no nsid, else the corresponding netns is checked (which may
> match the current netns).

OK.  It sounds like this one patch will not affect your use case than,
which is good to know.  Thanks!

> 
>>
>> Fixes: 59324cf35aba ("netlink: allow to listen "all" netns")
>> Reported-by: Matteo Perin <matteo.perin@canonical.com>
>> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
>> ---
>>  net/netlink/af_netlink.c | 8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
>> index 2aeb0680807d6..607ab4e4ac697 100644
>> --- a/net/netlink/af_netlink.c
>> +++ b/net/netlink/af_netlink.c
>> @@ -1482,9 +1482,11 @@ static void do_one_broadcast(struct sock *sk,
>>  		p->skb2 = NULL;
>>  		goto out;
>>  	}
>> -	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);
> 

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Nicolas Dichtel]

Le 18/05/2026 à 14:11, Ilya Maximets a écrit :
> On 5/18/26 8:21 AM, Jiri Benc wrote:
>> Hi Ilya,
> 
> Hi, Jiri.  Thanks for your thoughts on the matter!
> 
>>
>> 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.
> 
> Yeah, that's also what other projects like FRR are doing.  It's a bit
> of a hustle for multi-threaded applications, as AFAIK, there is no way
> to just move one thread into a different namespace, so if many threads
> are doing something with the network and you suddenly need to check
> something in a different namespace, you can't really do that without
> pausing all other threads first.  But that's a separate thing, unrelated
> to the series.  I'm just ranting. :) 
Hmm, not sure to understand. setns() is per thread (see man setns()).

> 
>>
>> 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'm not sure I would call this a bug; the original idea was to use
>> IFLA_IF_NETNSID to switch to the point of view of that netns but
>> without actually switching to that netns. Hence, the netnsid is
>> relative to the caller's netns but otherwise, you get the same reply as
>> you would if you switched to that netns. If you think about it that
>> way, the current reply is consistent.
> 
> It makes some sense, but the fact that all-nsid notification and the
> cross-namespace RTM_GETLINK provide different IDs makes it inconsistent
> in my brain.  We have:
> 
> 1. nsenter(target) + getlink(local) = target-to-link nsid.
> 2. getlink(target) = caller-to-target nsid  + caller-to-link nsid.
> 3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid.

all-nsid-notification appears before cross-getlink.
The goal, for all-nsid-notification, was to be able to receive netlink messages
of a subset of netns in one socket. So these messages are provided as-is, ie
like if they were sent on a netlink socket opened in the corresponding netns.
It's generic, there is no need to patch every subsystem.

cross-get*() have been added later. The chosen behavior is friendlier at the
cost of patching every subsystem that is supported.

[snip]

> If we don't consider this behavior as a bug than I'd rather just document
> it and solidify in tests, i.e. drop the code change and update the tests
> I made in the patch 2/5 to make it clear what is the actual behavior.
> If we change the logic in the next tree only, it will not be possible for
> applications to understand what is the behavior without checking the
> kernel version or introduction of extra flags, i.e. we'd have to make the
> new behavior opt-in.  Which may be fine, I suppose, but will require
> application changes to take advantage of.
+1

Regards,
Nicolas

Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Nicolas Dichtel]

Le 18/05/2026 à 14:46, Ilya Maximets a écrit :

[snip]

> True and also not really.  The main problem is that ID can be allocated
> at any point in time, so the application needs to listen for NEW messages
> on the same socket that it is listening for the events that are interesting
> to it (to avoid races), if it doesn't want to make a separate GET request
> per notification or track all the IDs that were previously checked.  It's a
> non-trivial amount of code depending on the application structure.
iproute2 handles it ;-)
You certainly need to maintain a cache, but once a nsid is allocated, it never
changes until the netns is deleted.

> 
> Alternative is to always try and allocate the self-referential mapping on
> the application startup and remember it, and then check that no-id, -1 and
> the allocated one all mean 'current'.Yep.

> 
>>
>>>
>>> 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.  Quite the opposite, ovs-vswitchd relies
>>> on the metadata to not be present to separate local and remote
>>> events.  And the 'ip monitor' relies on the metadata to not be present
>>> to show '[nsid current]', though this is more like "print 'current'
>>> if there is nothing to print" situation, but still can be a little
>>> confusing for the user to see an ID for a local event.
>>
>> We (6WIND) are using NETLINK_LISTEN_ALL_NSID. Like iproute2, 'current' is
>> assumed if there is no nsid, else the corresponding netns is checked (which may
>> match the current netns).
> 
> OK.  It sounds like this one patch will not affect your use case than,
> which is good to know.  Thanks!
Probably not, but I didn't say this ;-)
I need to make some tests with your series.

Regards,
Nicolas

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Ilya Maximets]

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.

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Ilya Maximets]

On 5/18/26 2:46 PM, Nicolas Dichtel wrote:
> Le 18/05/2026 à 14:11, Ilya Maximets a écrit :
>> On 5/18/26 8:21 AM, Jiri Benc wrote:
>>> Hi Ilya,
>>
>> Hi, Jiri.  Thanks for your thoughts on the matter!
>>
>>>
>>> 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.
>>
>> Yeah, that's also what other projects like FRR are doing.  It's a bit
>> of a hustle for multi-threaded applications, as AFAIK, there is no way
>> to just move one thread into a different namespace, so if many threads
>> are doing something with the network and you suddenly need to check
>> something in a different namespace, you can't really do that without
>> pausing all other threads first.  But that's a separate thing, unrelated
>> to the series.  I'm just ranting. :) 
> Hmm, not sure to understand. setns() is per thread (see man setns()).

Hmm, I got my wires crossed here with something else, I suppose.
Though CAP_SYS_ADMIN requirement may be an even higher barrier.

> 
>>
>>>
>>> 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'm not sure I would call this a bug; the original idea was to use
>>> IFLA_IF_NETNSID to switch to the point of view of that netns but
>>> without actually switching to that netns. Hence, the netnsid is
>>> relative to the caller's netns but otherwise, you get the same reply as
>>> you would if you switched to that netns. If you think about it that
>>> way, the current reply is consistent.
>>
>> It makes some sense, but the fact that all-nsid notification and the
>> cross-namespace RTM_GETLINK provide different IDs makes it inconsistent
>> in my brain.  We have:
>>
>> 1. nsenter(target) + getlink(local) = target-to-link nsid.
>> 2. getlink(target) = caller-to-target nsid  + caller-to-link nsid.
>> 3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid.
> 
> all-nsid-notification appears before cross-getlink.
> The goal, for all-nsid-notification, was to be able to receive netlink messages
> of a subset of netns in one socket. So these messages are provided as-is, ie
> like if they were sent on a netlink socket opened in the corresponding netns.
> It's generic, there is no need to patch every subsystem.
> 
> cross-get*() have been added later. The chosen behavior is friendlier at the
> cost of patching every subsystem that is supported.

That's exactly my point.  If we're creating a special patch for a subsystem, we
don't need to adhere to the exact structure of the original message, since the
data reported changes anyway.

IMO, not reporting nsid that is the same as the caller's nsid is more friendlier.
But that's, again, just a difference in opinion at this point, I'll not insist.

Best regards, Ilya Maximets.

Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Ilya Maximets]

On 5/18/26 2:56 PM, Nicolas Dichtel wrote:
> Le 18/05/2026 à 14:46, Ilya Maximets a écrit :
> 
> [snip]
> 
>> True and also not really.  The main problem is that ID can be allocated
>> at any point in time, so the application needs to listen for NEW messages
>> on the same socket that it is listening for the events that are interesting
>> to it (to avoid races), if it doesn't want to make a separate GET request
>> per notification or track all the IDs that were previously checked.  It's a
>> non-trivial amount of code depending on the application structure.
> iproute2 handles it ;-)

I don't think it does.  If I run this in one terminal:

ip netns add test-ns
ip netns exec test-ns ip monitor link all-nsid

And then in the other terminal:

ip -n test-ns link add dummy1 type dummy
ip netns exec test-ns ip netns set test-ns 100
ip -n test-ns link add dummy2 type dummy
ip netns del test-ns

I see the following events:

[nsid current]2: dummy1: <BROADCAST,NOARP> ...
[nsid 100]3: dummy2: <BROADCAST,NOARP> ...

Which is confusing to the user (myself) and shows that iproute2 doesn't
know or doesn't care (which may be fine for this particular command) that
100 is the ID of the current namespace.

> You certainly need to maintain a cache, but once a nsid is allocated, it never
> changes until the netns is deleted.
> 
>>
>> Alternative is to always try and allocate the self-referential mapping on
>> the application startup and remember it, and then check that no-id, -1 and
>> the allocated one all mean 'current'.Yep.
> 
>>
>>>
>>>>
>>>> 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.  Quite the opposite, ovs-vswitchd relies
>>>> on the metadata to not be present to separate local and remote
>>>> events.  And the 'ip monitor' relies on the metadata to not be present
>>>> to show '[nsid current]', though this is more like "print 'current'
>>>> if there is nothing to print" situation, but still can be a little
>>>> confusing for the user to see an ID for a local event.
>>>
>>> We (6WIND) are using NETLINK_LISTEN_ALL_NSID. Like iproute2, 'current' is
>>> assumed if there is no nsid, else the corresponding netns is checked (which may
>>> match the current netns).
>>
>> OK.  It sounds like this one patch will not affect your use case than,
>> which is good to know.  Thanks!
> Probably not, but I didn't say this ;-)
> I need to make some tests with your series.

Note: sashiko points out that it may be possible to have stale values reported, so
re-setting the nsid_is_set flag unconditionally before the check may be required,
e.g.:

+  NETLINK_CB(p->skb2).nsid_is_set = false;
   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;
   }

I'll include that in v2.

This appears to be a missed case of the earlier fix:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7212462fa6fd
But made worse by my patch.

Best regards, Ilya Maximets.

Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local

[Nicolas Dichtel]

Le 18/05/2026 à 15:55, Ilya Maximets a écrit :
> On 5/18/26 2:46 PM, Nicolas Dichtel wrote:
>> Le 18/05/2026 à 14:11, Ilya Maximets a écrit :
>>> On 5/18/26 8:21 AM, Jiri Benc wrote:
>>>> Hi Ilya,
>>>
>>> Hi, Jiri.  Thanks for your thoughts on the matter!
>>>
>>>>
>>>> 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.
>>>
>>> Yeah, that's also what other projects like FRR are doing.  It's a bit
>>> of a hustle for multi-threaded applications, as AFAIK, there is no way
>>> to just move one thread into a different namespace, so if many threads
>>> are doing something with the network and you suddenly need to check
>>> something in a different namespace, you can't really do that without
>>> pausing all other threads first.  But that's a separate thing, unrelated
>>> to the series.  I'm just ranting. :) 
>> Hmm, not sure to understand. setns() is per thread (see man setns()).
> 
> Hmm, I got my wires crossed here with something else, I suppose.
> Though CAP_SYS_ADMIN requirement may be an even higher barrier.
> 
>>
>>>
>>>>
>>>> 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'm not sure I would call this a bug; the original idea was to use
>>>> IFLA_IF_NETNSID to switch to the point of view of that netns but
>>>> without actually switching to that netns. Hence, the netnsid is
>>>> relative to the caller's netns but otherwise, you get the same reply as
>>>> you would if you switched to that netns. If you think about it that
>>>> way, the current reply is consistent.
>>>
>>> It makes some sense, but the fact that all-nsid notification and the
>>> cross-namespace RTM_GETLINK provide different IDs makes it inconsistent
>>> in my brain.  We have:
>>>
>>> 1. nsenter(target) + getlink(local) = target-to-link nsid.
>>> 2. getlink(target) = caller-to-target nsid  + caller-to-link nsid.
>>> 3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid.
>>
>> all-nsid-notification appears before cross-getlink.
>> The goal, for all-nsid-notification, was to be able to receive netlink messages
>> of a subset of netns in one socket. So these messages are provided as-is, ie
>> like if they were sent on a netlink socket opened in the corresponding netns.
>> It's generic, there is no need to patch every subsystem.
>>
>> cross-get*() have been added later. The chosen behavior is friendlier at the
>> cost of patching every subsystem that is supported.
> 
> That's exactly my point.  If we're creating a special patch for a subsystem, we
> don't need to adhere to the exact structure of the original message, since the
> data reported changes anyway.
Sure, but only for this special path then (ie cross-get). My understanding is
that you are interested by the all-nsid-notification path.

> 
> IMO, not reporting nsid that is the same as the caller's nsid is more friendlier.
> But that's, again, just a difference in opinion at this point, I'll not insist.
The problem is changing the netlink API. As you said, a new flag would be needed
for this.

Regards,
Nicolas

Re: [PATCH net 3/5] net: netlink: don't set nsid on local notifications

[Nicolas Dichtel]

Le 18/05/2026 à 16:06, Ilya Maximets a écrit :
> On 5/18/26 2:56 PM, Nicolas Dichtel wrote:
>> Le 18/05/2026 à 14:46, Ilya Maximets a écrit :
>>
>> [snip]
>>
>>> True and also not really.  The main problem is that ID can be allocated
>>> at any point in time, so the application needs to listen for NEW messages
>>> on the same socket that it is listening for the events that are interesting
>>> to it (to avoid races), if it doesn't want to make a separate GET request
>>> per notification or track all the IDs that were previously checked.  It's a
>>> non-trivial amount of code depending on the application structure.
>> iproute2 handles it ;-)
> 
> I don't think it does.  If I run this in one terminal:
> 
> ip netns add test-ns
> ip netns exec test-ns ip monitor link all-nsid
> 
> And then in the other terminal:
> 
> ip -n test-ns link add dummy1 type dummy
> ip netns exec test-ns ip netns set test-ns 100
> ip -n test-ns link add dummy2 type dummy
> ip netns del test-ns
> 
> I see the following events:
> 
> [nsid current]2: dummy1: <BROADCAST,NOARP> ...
> [nsid 100]3: dummy2: <BROADCAST,NOARP> ...
> 
> Which is confusing to the user (myself) and shows that iproute2 doesn't
> know or doesn't care (which may be fine for this particular command) that
> 100 is the ID of the current namespace.
Right, it doesn't update its cache. I thought I fixed this :D

[snip]

>> I need to make some tests with your series.
> 
> Note: sashiko points out that it may be possible to have stale values reported, so
> re-setting the nsid_is_set flag unconditionally before the check may be required,
> e.g.:
> 
> +  NETLINK_CB(p->skb2).nsid_is_set = false;
>    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;
>    }
> 
> I'll include that in v2.
I will wait for the v2 to test the series.

Regards,
Nicolas

Re: [PATCH net 4/5] tools: ynl: support listening on all nsids

[Jakub Kicinski]

On Fri, 15 May 2026 22:19:23 +0200 Ilya Maximets wrote:
> +    def ntf_listen_all_nsid(self):

doc-string needed

> +        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 +1251,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 +1262,20 @@ 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 check_ntf(self):
>          while True:
>              try:
> -                reply = self.sock.recv(self._recv_size, socket.MSG_DONTWAIT)
> +                reply, ancdata, _, _ = self.sock.recvmsg(self._recv_size,
> +                                                         4096,
> +                                                         socket.MSG_DONTWAIT)

please add a helper method (_recvmsg()?) that only takes flags
and doesn't return flags or addr since neither caller cares