Re: [PATCH net-next] ipv6: Serialize hardware flag notifications

[Ido Schimmel <idosch@nvidia.com>]

On Sat, Aug 15, 2026 at 06:54:36PM +0900, Yuyang Huang wrote:
> fib6_info_hw_flags_set() first performs a lockless check of fib6_node.
> It then allocates a notification skb with GFP_KERNEL, which can sleep. A
> concurrent route deletion can remove the route, set fib6_node to NULL, and
> emit RTM_DELROUTE while the allocation sleeps. When the thread wakes up,
> it can emit RTM_NEWROUTE for the already deleted route.
> 
> This can cause userspace routing daemons to receive RTM_DELROUTE followed
> by RTM_NEWROUTE and incorrectly believe that the deleted route still
> exists in the kernel.
> 
> Allocate the skb before taking tb6_lock, then recheck fib6_node while
> holding the lock. Keep the lock until RTM_NEWROUTE is published. If route
> deletion wins the race, the recheck sees NULL and drops the notification.
> Otherwise, deletion cannot remove the route until RTM_NEWROUTE has been
> published, preserving notification order.
> 
> RTM_DELROUTE is sent by fib6_del_route() with tb6_lock held, so
> publishing RTM_NEWROUTE under the same lock is sufficient to guarantee
> ordering. rt6_fill_node() does not sleep in this path, and the
> notification uses GFP_ATOMIC, matching inet6_rt_notify() which already
> broadcasts under tb6_lock.
> 
> The race was found by Sashiko during code review.

Yes, it's racy, but I don't have good solution that also covers IPv4.
IPv4 routes are protected by RTNL and taking RTNL in this path will
cause lock inversion.

Also, as far as I'm aware, this isn't a problem in practice. These
notifications (disabled by default) are mainly used by routing daemons
that want to suppress the advertisement of a route until it's offloaded.
If they added it and immediately deleted it, then it doesn't make sense
to advertise it.