[PATCH net-next 0/3] net: make moving a device to another netns cheaper

From: Qiliang Yuan

Date: Fri Oct 16 2026 - 02:10:09 EST


Moving a device to another netns waits in rcu_barrier() with RTNL held.
Container and sandbox managers move one end of a veth pair for every
new network namespace, so this barrier limits how fast such namespaces
can be created on the whole system, to about 75 per second in a 16
vCPU guest no matter how many threads create them.

The barrier was added for NETDEV_UNREGISTER_FINAL, which is long gone,
but it still keeps cached IPv4 routes through the moved device from
being accepted in the old netns. Routes through nexthop objects are not
covered by it: their cached dst entries are released by an RCU callback
queued from another RCU callback, so a socket in the old netns can still
send through a device that now belongs to another netns whenever the
route generation numbers of the two netns happen to match.

Patches 1 and 2 make the IPv4 rt_genid and the IPv6 fib6_sernum unique
across netns, which fixes that leak for nexthop objects and leaves
nothing that relies on the barrier. Patch 3 removes it. Patches 1 and 2
fix bugs that exist today and can go to net on their own if preferred.

Creating 400 netns, each with a veth pair whose host end is moved back
to the initial netns, a tap device, addresses and routes, median of 5
runs:

before after
1 thread 67 /s 440 /s
4 threads 75 /s 409 /s
16 threads 76 /s 283 /s

Signed-off-by: Qiliang Yuan <odys.yuan@xxxxxxxxx>
---
Qiliang Yuan (3):
ipv4: draw rt_genid from a sequence shared by all netns
ipv6: take fib6_sernum from a sequence shared by all netns
net: remove rcu_barrier() from __dev_change_net_namespace()

include/net/net_namespace.h | 5 +----
net/core/dev.c | 1 -
net/ipv4/route.c | 16 +++++++++++++++-
net/ipv6/af_inet6.c | 1 -
net/ipv6/ip6_fib.c | 14 ++++++++++++--
5 files changed, 28 insertions(+), 9 deletions(-)
---
base-commit: 6b3e73774815910a39d8ca75b9ad7df963f61d50
change-id: 20261016-bug-net-netns-move-rcu-barrier-d998c6395830

Best regards,
--
Qiliang Yuan <odys.yuan@xxxxxxxxx>