[PATCH net v2] selftests/net: run tun tests in a dedicated network namespace
From: Edoardo Canepa <hidden>
Date: 2026-09-14 21:19:30
Also in:
linux-kselftest, lkml
Subsystem:
kernel selftest framework, networking [general], the rest · Maintainers:
Shuah Khan, Shuah Khan, "David S. Miller", Eric Dumazet, Jakub Kicinski, Paolo Abeni, Linus Torvalds
The tun_vnet_udptnl fixture creates a fresh tap device and installs an
IPv6 outer neighbor entry as NUD_PERMANENT before sending packets. On
systems where systemd-udevd is running and a systemd .link file sets
MACAddressPolicy=persistent
(the default shipped by systemd in 99-default.link, so this is what
most systemd-based hosts inherit), systemd-udevd's net_setup_link
builtin asynchronously sends an RTM_SETLINK to reassign the freshly
created tap device's MAC to a machine-persistent value. When that
netlink message races the test's ip_neigh_add() call, the address
change kicks the following path:
do_setlink
-> netif_set_mac_address
-> call_netdevice_notifiers_info
-> ndisc_netdev_event
-> neigh_changeaddr
-> neigh_flush_dev(tbl, dev, /* skip_perm = */ false)
which flushes every neighbor entry on the interface, including the one
the test just installed as NUD_PERMANENT. The subsequent packet
therefore hits __neigh_create(), triggers NDISC, and times out with:
tun.c:947:send_gso_packet:Expected ret (0) == variant->data_size (1423)
tun.c:948:send_gso_packet:Expected r_num_mss (0) == variant->r_num_mss (2)
The failure is non-deterministic and can affect both directions. Both
recv_gso_packet and send_gso_packet variants can hit it; the failure
reproduces on a plain systemd-based VM with no containers, and is
triggered whenever the udev worker's RTM_SETLINK lands after the test
has installed its neighbor entry.
Fix by calling unshare(CLONE_NEWNET) from both fixture setups. The
harness runs each test in its own forked process, so every test gets a
private network namespace that is torn down with it, and all tap and
geneve devices are created in a namespace that systemd-udevd (running
in the init netns) does not watch, so its RTM_SETLINK never fires
against them.
Creating a network namespace needs CAP_SYS_ADMIN in the current user
namespace and CONFIG_NET_NS=y, neither of which the tests required
before. Where they are unavailable the unshare() is reported with
SKIP() rather than aborting, so the binary still emits a full TAP
stream and a runner can tell "network namespaces unavailable" apart
from a real tun/tap regression.
Verified on a plain systemd-based VM running the affected kernel, with
the tap and geneve devices removed between iterations so that each one
starts from a clean state. 1000 repeated invocations of
tun -r tun_vnet_udptnl.4in6_nogsosz_1byte.recv_gso_packet
produce 266 failures without the fix and zero failures with it, and a
full run of the test binary fails in 20 out of 20 attempts without the
fix and in zero out of 20 with it.
Note that without the fix a failure is not self-contained: the fixture
setup aborts before FIXTURE_TEARDOWN runs, so the tap and geneve
devices are left behind in the init netns and every later run fails
right away in geneve_create(). Running in a private namespace also
removes that, since the namespace is torn down with the test process.
Reported-by: Po-Hsu Lin <redacted>
Closes: https://bugs.launchpad.net/bugs/2158217
Fixes: 24e59f26eef2 ("selftest: tun: Add helpers for GSO over UDP tunnel")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Edoardo Canepa <redacted>
---
v2:
- Add the unshare(CLONE_NEWNET) to FIXTURE_SETUP(tun) and
FIXTURE_SETUP(tun_vnet_udptnl) instead of replacing
TEST_HARNESS_MAIN with a hand-written main(), as suggested by
Jakub.
- Report an unshare() failure with SKIP() instead of aborting the
binary before the harness starts, so the TAP stream stays complete
and a runner can tell "no network namespaces" apart from a real
tun/tap regression (raised by Sashiko).
- Mention the new CAP_SYS_ADMIN / CONFIG_NET_NS prerequisite in the
commit message (raised by Sashiko).
- Use the Assisted-by: format documented in
Documentation/process/coding-assistants.rst.
- Redo the measurements in the commit message. The v1 numbers were
taken without cleaning up the tap and geneve devices that a failed
run leaves behind, which made runs after the first failure fail in
geneve_create() rather than on the race being fixed here.
v1: https://lore.kernel.org/netdev/20260905085318.3416670-1-edoardo.canepa@canonical.com/ (local)
tools/testing/selftests/net/tun.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/tools/testing/selftests/net/tun.c b/tools/testing/selftests/net/tun.c
index abe488bac50b..6db21dad0efe 100644
--- a/tools/testing/selftests/net/tun.c
+++ b/tools/testing/selftests/net/tun.c@@ -4,6 +4,7 @@ #include <errno.h> #include <fcntl.h> +#include <sched.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
@@ -488,6 +489,10 @@ FIXTURE(tun) FIXTURE_SETUP(tun) { + if (unshare(CLONE_NEWNET)) + SKIP(return, "Cannot create network namespace: %s", + strerror(errno)); + memset(self->ifname, 0, sizeof(self->ifname)); self->fd = tun_alloc(self->ifname);
@@ -732,6 +737,10 @@ FIXTURE_SETUP(tun_vnet_udptnl) struct sockaddr_storage ssa, dsa; void *sip, *dip, *smac, *dmac; + if (unshare(CLONE_NEWNET)) + SKIP(return, "Cannot create network namespace: %s", + strerror(errno)); + flags = (variant->is_tap ? IFF_TAP : IFF_TUN) | IFF_VNET_HDR | IFF_MULTI_QUEUE | IFF_NO_PI; features = TUN_F_CSUM | TUN_F_UDP_TUNNEL_GSO |
--
2.53.0