Anton Danilov wrote: > When a UDP encapsulation socket (e.g., FOU) receives a multicast > packet, __udp4_lib_mcast_deliver() and __udp6_lib_mcast_deliver() > call consume_skb() when udp_queue_rcv_skb() returns a positive value. > A positive return value from udp_queue_rcv_skb() indicates that the > encap_rcv handler (e.g., fou_udp_recv) has consumed the UDP header > and wants the packet to be resubmitted to the IP protocol handler > for further processing (e.g., as a GRE packet). > > The unicast paths handle this correctly by propagating the return > value up to ip_protocol_deliver_rcu() / ip6_protocol_deliver_rcu() > for resubmission. However, the multicast paths destroy the packet > via consume_skb() instead of resubmitting it, causing silent packet > loss. > > This affects any UDP encapsulation (FOU, GUE) combined with multicast > destination addresses. > > Fix this by returning the value from udp_queue_rcv_skb() when it is > positive, matching the behavior of the corresponding unicast paths. > Note the sign difference between IPv4 and IPv6: > > - IPv4: udp_unicast_rcv_skb() returns -ret, and > ip_protocol_deliver_rcu() resubmits when ret < 0 > (using -ret as the protocol number). > - IPv6: udp6_unicast_rcv_skb() returns ret, and > ip6_protocol_deliver_rcu() resubmits when ret > 0 > (using ret as the nexthdr). > > Both mcast paths now follow the same convention as their respective > unicast paths. > > Suggested-by: Willem de Bruijn <[email protected]>
Please drop. No need for this based on just feedback to a previous version. > Suggested-by: Kuniyuki Iwashima <[email protected]> > Signed-off-by: Anton Danilov <[email protected]> > Assisted-by: Claude:claude-opus-4-6 With that aside Reviewed-by: Willem de Bruijn <[email protected]>
