Re: [PATCH net-next v6 1/2] udp: fix encapsulation packet resubmit in multicast deliver

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Anton Danilov wrote:
> 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.

Thanks for that context. No need to respin for that.