[PATCH net v3] selftests/net: run tun tests in a dedicated network namespace

[PATCH net v3] selftests/net: run tun tests in a dedicated network namespace

[Edoardo Canepa]

The tun_vnet_udptnl fixture creates a fresh tap device, assigns it a
fixed MAC address and installs the outer neighbor entry as
NUD_PERMANENT.  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
lands after the fixture has configured the device, both directions
break:

- recv_gso_packet transmits through the tap, and the address change
  flushes the neighbor entry the fixture installed:

    do_setlink
    -> netif_set_mac_address
       -> call_netdevice_notifiers(NETDEV_CHANGEADDR)
          -> ndisc_netdev_event (arp_netdev_event for an IPv4 outer)
             -> neigh_changeaddr
                -> neigh_flush_dev(tbl, dev, /* skip_perm = */ false)

  so the packet hits __neigh_create() and waits on neighbor resolution
  that never completes.

- send_gso_packet writes frames addressed to the MAC the fixture
  assigned.  Once the tap has a different address, eth_type_trans()
  marks them PACKET_OTHERHOST and the IP receive path drops them.

Either way nothing arrives before the receive timeout, and the test
fails with, for example:

  tun.c:947:send_gso_packet:Expected ret (0) == variant->data_size (1)
  tun.c:948:send_gso_packet:Expected r_num_mss (0) == variant->r_num_mss (1)
  tun.c:962:recv_gso_packet:Expected ret (0) == variant->data_size (1)

The failure is non-deterministic and reproduces on a plain
systemd-based VM with no containers.

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.
Without the fix, 1000 sequential invocations of

  tun -r tun_vnet_udptnl.4in6_nogsosz_1byte.recv_gso_packet

fail 10 times, and 2 out of 20 full runs of the test binary fail.  With
the fix there are no failures in either case.

Reported-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Closes: https://bugs.launchpad.net/bugs/2158217
Fixes: 24e59f26eef2 ("selftest: tun: Add helpers for GSO over UDP tunnel")
Assisted-by: LLM
Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com>
---
v3:
  - Drop the claim that a failure leaves the tap and geneve devices
    behind.  The failing checks are EXPECT_EQ()s in the test body, so
    FIXTURE_TEARDOWN still runs (Sashiko).
  - Explain the send_gso_packet failure correctly: its frames are
    dropped as PACKET_OTHERHOST once the tap's MAC changes.  The
    neighbor flush only affects recv_gso_packet.
  - Redo the measurements on a freshly booted host.  The v2 numbers
    were taken in an unclean environment.  The v1 numbers were fine,
    and the v2 entry saying otherwise was wrong.
  - Go back to "Assisted-by: LLM", the current format in
    Documentation/process/coding-assistants.rst.  v2 followed an older
    copy of that document (Sashiko).
v2: https://lore.kernel.org/netdev/20260914211921.3786609-1-edoardo.canepa@canonical.com/
  - 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() (Jakub).
  - Report an unshare() failure with SKIP() instead of aborting the
    binary before the harness starts (Sashiko).
  - Mention the new CAP_SYS_ADMIN / CONFIG_NET_NS prerequisite in the
    commit message (Sashiko).
  - Change the Assisted-by: format (reverted in v3).
  - Redo the measurements (redone again in v3).
v1: https://lore.kernel.org/netdev/20260905085318.3416670-1-edoardo.canepa@canonical.com/
 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

Re: [PATCH net v3] selftests/net: run tun tests in a dedicated network namespace

[Simon Horman]

On Thu, Sep 17, 2026 at 01:15:20PM +0200, Edoardo Canepa wrote:
> The tun_vnet_udptnl fixture creates a fresh tap device, assigns it a
> fixed MAC address and installs the outer neighbor entry as
> NUD_PERMANENT.  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
> lands after the fixture has configured the device, both directions
> break:
> 
> - recv_gso_packet transmits through the tap, and the address change
>   flushes the neighbor entry the fixture installed:
> 
>     do_setlink
>     -> netif_set_mac_address
>        -> call_netdevice_notifiers(NETDEV_CHANGEADDR)
>           -> ndisc_netdev_event (arp_netdev_event for an IPv4 outer)
>              -> neigh_changeaddr
>                 -> neigh_flush_dev(tbl, dev, /* skip_perm = */ false)
> 
>   so the packet hits __neigh_create() and waits on neighbor resolution
>   that never completes.
> 
> - send_gso_packet writes frames addressed to the MAC the fixture
>   assigned.  Once the tap has a different address, eth_type_trans()
>   marks them PACKET_OTHERHOST and the IP receive path drops them.
> 
> Either way nothing arrives before the receive timeout, and the test
> fails with, for example:
> 
>   tun.c:947:send_gso_packet:Expected ret (0) == variant->data_size (1)
>   tun.c:948:send_gso_packet:Expected r_num_mss (0) == variant->r_num_mss (1)
>   tun.c:962:recv_gso_packet:Expected ret (0) == variant->data_size (1)
> 
> The failure is non-deterministic and reproduces on a plain
> systemd-based VM with no containers.
> 
> 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.
> Without the fix, 1000 sequential invocations of
> 
>   tun -r tun_vnet_udptnl.4in6_nogsosz_1byte.recv_gso_packet
> 
> fail 10 times, and 2 out of 20 full runs of the test binary fail.  With
> the fix there are no failures in either case.
> 
> Reported-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
> Closes: https://bugs.launchpad.net/bugs/2158217
> Fixes: 24e59f26eef2 ("selftest: tun: Add helpers for GSO over UDP tunnel")
> Assisted-by: LLM
> Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com>
> ---
> v3:
>   - Drop the claim that a failure leaves the tap and geneve devices
>     behind.  The failing checks are EXPECT_EQ()s in the test body, so
>     FIXTURE_TEARDOWN still runs (Sashiko).
>   - Explain the send_gso_packet failure correctly: its frames are
>     dropped as PACKET_OTHERHOST once the tap's MAC changes.  The
>     neighbor flush only affects recv_gso_packet.
>   - Redo the measurements on a freshly booted host.  The v2 numbers
>     were taken in an unclean environment.  The v1 numbers were fine,
>     and the v2 entry saying otherwise was wrong.
>   - Go back to "Assisted-by: LLM", the current format in
>     Documentation/process/coding-assistants.rst.  v2 followed an older
>     copy of that document (Sashiko).
> v2: https://lore.kernel.org/netdev/20260914211921.3786609-1-edoardo.canepa@canonical.com/
>   - 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() (Jakub).
>   - Report an unshare() failure with SKIP() instead of aborting the
>     binary before the harness starts (Sashiko).
>   - Mention the new CAP_SYS_ADMIN / CONFIG_NET_NS prerequisite in the
>     commit message (Sashiko).
>   - Change the Assisted-by: format (reverted in v3).
>   - Redo the measurements (redone again in v3).
> v1: https://lore.kernel.org/netdev/20260905085318.3416670-1-edoardo.canepa@canonical.com/

Reviewed-by: Simon Horman <horms@kernel.org>