Re: [PATCH net-next v2 1/3] ipv4: draw rt_genid from a sequence shared by all netns

[Kuniyuki Iwashima]

On Mon, 19 Oct 2026 11:31:15 +0800, Qiliang Yuan wrote:
> An IPv4 route records the rt_genid of the netns it was created in, and
> rt_is_expired() compares it with the rt_genid of the netns its device
> belongs to when the route is checked. Every netns starts its rt_genid
> at 0 and increments it on each cache flush, so different netns often
> hold the same value.
> 
> When a device moves to another netns, routes cached through it remain
> usable until dst_dev_put() points them to blackhole_netdev. For a route
> using a nexthop object this happens in nexthop_free_rcu(), which
> free_fib_info_rcu() queues from inside an RCU callback, so the
> rcu_barrier() in __dev_change_net_namespace() does not wait for it. If
> the rt_genid of the new netns matches the cached one in that window,
> ipv4_dst_check() accepts the route and a socket in the old netns keeps
> sending through a device that now belongs to another netns.
> 
> Take every rt_genid bump from one sequence shared by all netns, which
> never hands out 0, the value every netns starts with. A netns bumps its
> rt_genid on NETDEV_UP before its devices can carry traffic, so a cached
> route never matches the rt_genid of the netns its device moves to.
> Concurrent bumps of one netns can leave the older of two values, so
> rt_genid is no longer monotonic per netns. It is only compared for
> equality, so this costs at most an extra route lookup.
> 
> A connected UDP socket in netns A caches a route through a nexthop
> object on a veth. The veth is moved to netns B and brought up with one
> RTM_NEWLINK, then the socket sends 200000 datagrams. B's rt_genid is
> bumped 0 to 20 times before the move, 63 trials:
> 
>                                 before     after
>   trials sending after move          2         0
>   datagrams sent after move       2616         0
> 
> Fixes: 4c7e8084fd46 ("ipv4: Plumb support for nexthop object in a fib_info")
> Signed-off-by: Qiliang Yuan <odys.yuan@xxxxxxxxx>

Reviewed-by: Kuniyuki Iwashima <kuniyu@xxxxxxxxxx>