Re: [PATCH v2 net] udp: restore hlist_nulls for primary and secondary hash tables

[David Laight <david.laight.linux@gmail.com>]

On Tue, 3 Nov 2026 14:34:29 +0100
Eric Dumazet <edumazet@kernel.org> wrote:

> Le mar. 3 nov. 2026 à 09:40, Paolo Abeni <pabeni@redhat.com> a écrit :
> >
> > On 11/2/26 13:22, netdev-bot+sashiko@kernel.org wrote:  
> > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > issue(s) to consider.
> > >
> > > Critical: 0 · High: 1 · Medium: 0 · Low: 0
> > >
> > > If you believe none of the issues are legitimate, please reply to each
> > > issue of Medium severity or higher and explain why the AI is wrong.
> > > If any of them are legitimate and you plan to respin, please let patchwork
> > > know by including "pw-bot: cr" as a separate line at the end of your reply
> > > (one such reply per series is enough).
> > >
> > > - [High] The hlist_nulls restart does not work when an IPv6 SO_REUSEPORT
> > >    socket is tail-inserted back into the bucket it was just removed from.  
> >
> > This look real to me. On the flip side the most straight forward fix - avoid
> > tail insertion in udp_lib_get_port() would re-introduce the issue addressed
> > by commit d894ba18d4e449b3a7f6eb491f16c9e02933736e. But rehash already avoids
> > tail insertion...  
> 
> Agreed, it is real, although not a regression: before this patch,
> hlist_add_tail_rcu() set n->next = NULL and a reader parked on the
> socket stopped there as well. v2 simply did not fix this case.
> 
> We still need the tail insertion: udp4_lib_lookup2() returns as soon
> as the first matching socket has a reuseport group without connections,
> so a dual-stack IPv6 group placed first would win over AF_INET sockets,
> despite their better score.
> 
> The problem only exists while a reader can still be parked on the
> socket, that is less than an RCU grace period after udp_lib_unhash().
> 
> v3 records get_state_synchronize_rcu() in udp_lib_unhash(), and
> udp_lib_get_port() only uses tail insertion if
> poll_state_synchronize_rcu() says the grace period has elapsed,
> otherwise it uses head insertion, as udp_lib_rehash() already does.
> The cookie fits in an existing hole of struct udp_sock.
> 
> The cost is that an IPv6 SO_REUSEPORT socket rebound within a grace
> period of its disconnect keeps its head position, so the v4/v6 ordering
> is not enforced for it, the same as after a rehash today. This needs
> disconnect() then bind() on the same port, with AF_INET and dual-stack
> AF_INET6 reuseport sockets sharing that port.
> 
> I also kept sk_nulls_add_node_rcu() unchanged, the tail insertion logic
> is now local to UDP.

Is there a different issue that is a socket is rehashed there is a chance
that it ends up back on the same list.
If that happens you need it to stay in the same place (if possible),
certainly moving it to the end would mean that a reader could miss out
some items but not see a different nulls value.

There is an even more unlikely possibility of a reader starting on chain A,
being moved to chain B, and then back to A - so missing some items on A.
Probably just worth noting that it is extremely unlikely.

David

> 
> Thanks !
> 
> pw-bot: cr