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.
