On Wed, Jul 08, 2026 at 09:24:10PM -0400, Willem de Bruijn wrote:

This helps the case of one encap_rcv socket in the multicast receiver
group, so is a useful fix on its own.

But is Sashiko correct that this would still leave the same issue for
other sockets in the group? If so, something to address in this series
or leave for later?

Might be worthwhile to extend the test to capture that case too.

The clone loop is not reachable for encapsulation sockets, so there is
no remaining gap.

FOU/GUE tunnel sockets are created via udp_sock_create() /
setup_udp_tunnel_sock() and do not set SO_REUSEADDR or SO_REUSEPORT.
Without either, a UDP socket cannot share its port, so an encap socket
is always the only socket bound to its port. In
__udp[46]_lib_mcast_deliver() it is therefore always delivered as
'first', and the clone loop -- which handles the second and subsequent
sockets in the group -- never runs for it. The positive (resubmit)
return from udp_queue_rcv_skb() only happens for encap sockets; plain
UDP sockets return 0 or a negative value there. So the resubmit case
in the clone loop cannot occur.

For the same reason a selftest cannot exercise it: a second socket
cannot bind to the FOU port.

If useful, I can add a brief comment above the clone loop documenting
why no resubmit is needed there.