--- v3
+++ v1
@@ -1,32 +1,18 @@
-If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
-are UDP tunnels available in the system, udp_gro_receive() could end-up
-doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
-the outer UDP tunnel level for packets effectively carrying and UDP
-tunnel header.
+If UDP GRO forwarding (or list) is enabled, and there are
+udp tunnel available in the system, we could end-up doing L4
+aggregation for packets targeting the UDP tunnel.
 
-That could cause inner protocol corruption. If e.g. the relevant
-packets carry a vxlan header, different vxlan ids will be ignored/
-aggregated to the same GSO packet. Inner headers will be ignored, too,
-so that e.g. TCP over vxlan push packets will be held in the GRO
-engine till the next flush, etc.
+That could inner protocol corruption, as no overaly network
+parameters is taken in account at aggregation time.
 
-Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
-current packet could land in a UDP tunnel, and let udp_gro_receive()
-do GRO via udp_sk(sk)->gro_receive.
-
-The check implemented in this patch is broader than what is strictly
-needed, as the existing UDP tunnel could be e.g. configured on top of
-a different device: we could end-up skipping GRO at-all for some packets.
-
-Anyhow, that is a very thin corner case and covering it will add quite
-a bit of complexity.
-
-v1 -> v2:
- - hopefully clarify the commit message
+Just skip the fwd GRO if this packet could land in an UDP
+tunnel. The current check is broader than what is strictly
+needed, as the UDP tunnel could be e.g. on top of a different
+device, but is simple and the performance downside looks not
+relevant.
 
 Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
 Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
-Reviewed-by: Willem de Bruijn <willemb@google.com>
 Signed-off-by: Paolo Abeni <pabeni@redhat.com>
 ---
  net/ipv4/udp_offload.c | 19 +++++++++++--------