Re: [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536
From: Alice Mikityanska <hidden>
Date: 2026-07-16 17:05:01
On Thu, 16 Jul 2026 at 17:48, Simon Horman [off-list ref] wrote:
quoted hunk ↗ jump to hunk
This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev ------ Patch [4]: [PATCH net-next v9 4/9] udp: Support gro_ipv4_max_size > 65536 ---commit 6dfda0f76318408b2e2b33603d561940b926529c Author: Alice Mikityanska [off-list ref] Subject: udp: Support gro_ipv4_max_size > 65536 This commit fixes UDP GRO aggregation for packets larger than 65536 bytes by setting the UDP length field to 0 during GRO and restoring the true length from skb->len in udp_rcv().quoted
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 493e2b9e16fbc..4f9a3922937cc 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c@@ -919,7 +919,7 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff, struct sock *sk; int err; - udp_set_len_short(uh, newlen); + udp_set_len(uh, newlen);[Severity: High] Does setting the UDP length to 0 here (for packets > 65535 bytes) break software segmentation? In net/ipv4/udp_offload.c:__udp_gso_segment(), the code adjusts the pseudo-header checksum by subtracting uh->len: check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen)); If uh->len is 0 for BIG TCP packets, this subtraction will fail to remove the true 32-bit original length from the checksum.
I've already replied to this AI review comment before, and it's mentioned in the cover letter. I don't get why Sashiko keeps reporting it. For BIG TCP inside a UDP tunnel, the SKB doesn't go to __udp_gso_segment, but rather to __skb_udp_tunnel_segment.
Similarly, in net/ipv4/udp_offload.c:__skb_udp_tunnel_segment(), partial
GSO relies on uh->len to negate the old length:
if (skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL)
partial = (__force __wsum)uh->len;
else
partial = (__force __wsum)htonl(skb->len);
partial = csum_sub(csum_unfold(uh->check), partial);
Will forwarding BIG TCP over UDP packets that fall back to software
segmentation result in corrupted checksums for all generated segments?No, and it's verified by the selftest that also covers csum offload off now. Normally, gso_type for tunneled BIG TCP packets won't have SKB_GSO_PARTIAL set, because udp_gro_complete replaces gso_type with either SKB_GSO_UDP_TUNNEL_CSUM or SKB_GSO_UDP_TUNNEL. This way, we'll get to the correct branch and subtract skb->len. SKB_GSO_PARTIAL is only set by skb_segment, which is called after this check. In some very convoluted hypothetical scenario, if we have to reenter __skb_udp_tunnel_segment for the second time, this time with SKB_GSO_PARTIAL, it will still be correct to take uh->len this time, because partial GSO packets have a UDP length set to wire MSS.