selftests/net: run tun tests in a dedicated network namespace

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
Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260917111520.2614448-1-edoardo.canepa@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

0 files changed, 0 insertions, 0 deletions