Le dim. 11 oct. 2026 à 03:41, Brad Fitzpatrick via B4 Relay <[email protected]> a écrit : > > From: Brad Fitzpatrick <[email protected]> > > gre_gro_complete() assigns SKB_GSO_GRE to gso_type rather than OR-ing > it in. When GRE is carried over UDP by FOU or GUE, udp_gro_complete() > has already set SKB_GSO_UDP_TUNNEL{,_CSUM} before calling into the FOU > or GUE gro_complete handler and then gre_gro_complete(), so that bit is > lost. > > That has broken forwarding of such packets since FOU gained GRO: if a > host with a FOU or GUE socket on the tunnel's port merges transit > packets and then forwards them out a device that can't segment them > itself, udp4_ufo_fragment() finds neither tunnel bit and fails, and > the packets are dropped. Since commit 3d010c8031e3 ("udp: do not accept > non-tunnel GSO skbs landing in a tunnel"), local receive is broken too: > udp_unexpected_gso() considers the merged skb, which reaches the > encapsulation socket without either UDP tunnel bit, unexpected and > hands it to udp_rcv_segment(). Segmenting fails, so the packet is > freed and counted in UdpInErrors. Either way, only packets GRO didn't > merge get through, so TCP over FOU or GUE GRE tunnels slows to about > one segment per round trip whenever the receiving device has GRO > enabled. > > OR in SKB_GSO_GRE instead, as ipip_gro_complete() and > sit_gro_complete() do for SKB_GSO_IPXIP4. For plain GRE, gso_type is > still zero at this point unless the driver set it, so nothing changes > there in the usual case. > > The assignment dates to commit bf5a755f5e91 ("net-gre-gro: Add GRE > support to the GRO stack"), but nothing set gso_type before it until > FOU GRO came along, so the Fixes tag points there. > > Tested under virtme-ng with bulk TCP over a GRE tunnel between two > network namespaces joined by a veth, with GRO on the receiving veth and > segmentation off on the sending one, so GRO sees wire-sized packets. > 32 MiB took: > > before after > FOU over IPv4 26.0s, 9658 UDP errors 0.28s, 0 errors > GUE over IPv4 26.1s, 9686 UDP errors 0.39s, 0 errors > FOU over IPv6 26.4s, 9860 UDP errors 0.16s, 0 errors > plain GRE 0.17s 0.15s > > Forwarding the same FOU traffic through a third namespace with its own > FOU socket on the port, GRO on its ingress and segmentation off on its > egress, took 26.0s with 4826 egress drops before and 0.31s with none > after. On v6.8, before 3d010c8031e3, local receive was fine but > forwarding failed the same way (25.7s, 4764 drops). > > With GRO off on the receiver, all took under 0.2s both before and > after. The gre_gso.sh and fou_mcast_encap.sh selftests give the same > results before and after. > > Fixes: afe93325bc02 ("fou: Add GRO support") > Assisted-by: LLM > Signed-off-by: Brad Fitzpatrick <[email protected]> > ---
Nice catch, thanks. Reviewed-by: Eric Dumazet <[email protected]>
