AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/07/07 02:47	flow	patch-triage	29m Args: null Results: { "EnableConfigs": [ "VXLAN", "GENEVE", "NET_FOU", "INET_ESP", "INET6_ESP", "L2TP", "IP_VS", "AMT", "WIREGUARD", "6LOWPAN_NHC_UDP", "NF_NAT_SNMP_BASIC", "NET_ACT_CSUM", "RDMA_RXE", "NETDEVSIM", "INET_PSP" ], "FocusSymbols": [ "__udp_gso_segment", "udp_gro_complete", "udp4_gro_complete", "udp6_gro_complete", "udp_tunnel_xmit_skb", "udp_tunnel6_xmit_skb", "__skb_udp_tunnel_segment", "udp_gro_receive_segment", "fou_build_udp", "fou6_build_udp", "esp_output_udp_encap", "esp6_output_udp_encap", "l2tp_xmit_core", "ipvs_gue_encap", "tso_build_hdr", "skb_segment", "amt_send_discovery", "nsim_do_psp", "psp_write_headers", "nat_keepalive_send", "tcf_csum_ipv4_udp", "tcf_csum_ipv6_udp", "nf_nat_mangle_udp_packet", "udp_error", "snmp_translate", "udp_uncompress", "prepare_skb_header", "rdma_build_skb", "rxe_udp_encap_recv", "efx_gen_tun_header_udp", "i40e_tso", "iavf_tso", "ice_tso", "idpf_tso", "otx2_sqe_add_ext", "mlx5e_shampo_update_ipv4_udp_hdr", "mlx5e_shampo_update_ipv6_udp_hdr", "inet_rtm_getroute_build_skb", "fill_packet_ipv4", "fill_packet_ipv6" ], "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.", "WorthFuzzing": true }
1/1	2026/07/07 02:47	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit a82ad991569e9e2986e7c0d714f5587f5ee69273\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Tue Jul 7 02:47:49 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/infiniband/core/lag.c b/drivers/infiniband/core/lag.c\nindex 8fd80adfe833e7..00fe241737ffee 100644\n--- a/drivers/infiniband/core/lag.c\n+++ b/drivers/infiniband/core/lag.c\n@@ -36,7 +36,7 @@ static struct sk_buff rdma_build_skb(struct net_device netdev,\n \tuh-\u003esource =\n \t\thtons(rdma_flow_label_to_udp_sport(ah_attr-\u003egrh.flow_label));\n \tuh-\u003edest = htons(ROCE_V2_UDP_DPORT);\n-\tuh-\u003elen = htons(sizeof(struct udphdr));\n+\tudp_set_len_short(uh, sizeof(struct udphdr));\n \n \tif (is_ipv4) {\n \t\tskb_push(skb, sizeof(struct iphdr));\ndiff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c\nindex 3741b2c4b0bbfd..53daaf4c1eb2e0 100644\n--- a/drivers/infiniband/sw/rxe/rxe_net.c\n+++ b/drivers/infiniband/sw/rxe/rxe_net.c\n@@ -242,7 +242,7 @@ static int rxe_udp_encap_recv(struct sock sk, struct sk_buff skb)\n \tpkt-\u003eport_num = 1;\n \tpkt-\u003ehdr = (u8 )(udph + 1);\n \tpkt-\u003emask = RXE_GRH_MASK;\n-\tpkt-\u003epaylen = be16_to_cpu(udph-\u003elen) - sizeof(udph);\n+\tpkt-\u003epaylen = udp_get_len_short(udph) - sizeof(udph);\n \n \t/ remove udp header /\n \tskb_pull(skb, sizeof(struct udphdr));\n@@ -305,7 +305,7 @@ static void prepare_udp_hdr(struct sk_buff skb, __be16 src_port,\n \n \tudph-\u003edest = dst_port;\n \tudph-\u003esource = src_port;\n-\tudph-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len_short(udph, skb-\u003elen);\n \tudph-\u003echeck = 0;\n }\n \ndiff --git a/drivers/net/amt.c b/drivers/net/amt.c\nindex 5cf97c65576fc2..a44ffbb1816523 100644\n--- a/drivers/net/amt.c\n+++ b/drivers/net/amt.c\n@@ -667,7 +667,7 @@ static void amt_send_discovery(struct amt_dev amt)\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003egw_port;\n \tudph-\u003edest\t= amt-\u003erelay_port;\n-\tudph-\u003elen\t= htons(sizeof(udph) + sizeof(amtd));\n+\tudp_set_len_short(udph, sizeof(udph) + sizeof(amtd));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n@@ -760,7 +760,7 @@ static void amt_send_request(struct amt_dev amt, bool v6)\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003egw_port;\n \tudph-\u003edest\t= amt-\u003erelay_port;\n-\tudph-\u003elen\t= htons(sizeof(amtrh) + sizeof(udph));\n+\tudp_set_len_short(udph, sizeof(amtrh) + sizeof(udph));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n@@ -2611,7 +2611,7 @@ static void amt_send_advertisement(struct amt_dev amt, __be32 nonce,\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003erelay_port;\n \tudph-\u003edest\t= dport;\n-\tudph-\u003elen\t= htons(sizeof(amta) + sizeof(udph));\n+\tudp_set_len_short(udph, sizeof(amta) + sizeof(udph));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\ndiff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c\nindex 894f2d06d39d07..ef5e657816f005 100644\n--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c\n+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c\n@@ -3129,7 +3129,7 @@ static int i40e_tso(struct i40e_tx_buffer first, u8 hdr_len,\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/ determine offset of outer transport header /\n \t\t\tl4_offset = l4.hdr - skb-\u003edata;\ndiff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c\nindex 363c42bf3dcfee..c30abf17cf5d3c 100644\n--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c\n+++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c\n@@ -1774,7 +1774,7 @@ static int iavf_tso(struct iavf_tx_buffer first, u8 hdr_len,\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/ determine offset of outer transport header /\n \t\t\tl4_offset = l4.hdr - skb-\u003edata;\ndiff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c\nindex 4ca1a0602307d0..fdea2758adf155 100644\n--- a/drivers/net/ethernet/intel/ice/ice_txrx.c\n+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c\n@@ -1893,7 +1893,7 @@ int ice_tso(struct ice_tx_buf first, struct ice_tx_offload_params off)\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/ determine offset of outer transport header /\n \t\t\tl4_start = (u8)(l4.hdr - skb-\u003edata);\ndiff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c\nindex 7f9056404f64fc..566b08ca3a6cb1 100644\n--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c\n+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c\n@@ -2871,7 +2871,7 @@ int idpf_tso(struct sk_buff skb, struct idpf_tx_offload_params off)\n \t\t\t\t (__force __wsum)htonl(paylen));\n \t\t/ compute length of segmentation header /\n \t\toff-\u003etso_hdr_len = sizeof(struct udphdr) + l4_start;\n-\t\tl4.udp-\u003elen = htons(shinfo-\u003egso_size + sizeof(struct udphdr));\n+\t\tudp_set_len_short(l4.udp, shinfo-\u003egso_size + sizeof(struct udphdr));\n \t\tbreak;\n \tdefault:\n \t\treturn -EINVAL;\ndiff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\nindex 625bb5a05344c0..8d2d607bc92f9c 100644\n--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\n+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\n@@ -750,7 +750,7 @@ static void otx2_sqe_add_ext(struct otx2_nic pfvf, struct otx2_snd_queue sq,\n \t\t\t\text-\u003elso_format = pfvf-\u003ehw.lso_udpv6_idx;\n \t\t\t}\n \n-\t\t\tudph-\u003elen = htons(sizeof(struct udphdr));\n+\t\t\tudp_set_len_short(udph, sizeof(struct udphdr));\n \t\t}\n \t} else if (skb_shinfo(skb)-\u003etx_flags \u0026 SKBTX_HW_TSTAMP) {\n \t\text-\u003etstmp = 1;\ndiff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\nindex 6fbc0441c4b845..04af54b704d823 100644\n--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\n+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\n@@ -1081,7 +1081,7 @@ static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq rq, struct iphdr \n \tstruct udphdr uh;\n \n \tuh = (struct udphdr )(skb-\u003edata + udp_off);\n-\tuh-\u003elen = htons(skb-\u003elen - udp_off);\n+\tudp_set_len_short(uh, skb-\u003elen - udp_off);\n \n \tif (uh-\u003echeck)\n \t\tuh-\u003echeck = ~udp_v4_check(skb-\u003elen - udp_off, ipv4-\u003esaddr,\n@@ -1100,7 +1100,7 @@ static void mlx5e_shampo_update_ipv6_udp_hdr(struct mlx5e_rq rq, struct ipv6hdr\n \tstruct udphdr uh;\n \n \tuh = (struct udphdr )(skb-\u003edata + udp_off);\n-\tuh-\u003elen = htons(skb-\u003elen - udp_off);\n+\tudp_set_len_short(uh, skb-\u003elen - udp_off);\n \n \tif (uh-\u003echeck)\n \t\tuh-\u003echeck = ~udp_v6_check(skb-\u003elen - udp_off, \u0026ipv6-\u003esaddr,\ndiff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\nindex accc26d1a872db..1dcdb86690bb74 100644\n--- a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\n+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\n@@ -113,7 +113,7 @@ static struct sk_buff mlx5e_test_get_udp_skb(struct mlx5e_priv priv)\n \t/* Fill UDP header /\n \tudph-\u003esource = htons(9);\n \tudph-\u003edest = htons(9); / Discard Protocol /\n-\tudph-\u003elen = htons(sizeof(struct mlx5ehdr) + sizeof(struct udphdr));\n+\tudp_set_len_short(udph, sizeof(struct mlx5ehdr) + sizeof(struct udphdr));\n \tudph-\u003echeck = 0;\n \n \t/ Fill IP header /\ndiff --git a/drivers/net/ethernet/sfc/falcon/selftest.c b/drivers/net/ethernet/sfc/falcon/selftest.c\nindex db4dd7fb77f5cb..4d29e0baf2ebe5 100644\n--- a/drivers/net/ethernet/sfc/falcon/selftest.c\n+++ b/drivers/net/ethernet/sfc/falcon/selftest.c\n@@ -401,8 +401,8 @@ static void ef4_iterate_state(struct ef4_nic efx)\n \n \t/* Initialise udp header /\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(payload) -\n-\t\t\t\t offsetof(struct ef4_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(payload) -\n+\t\t\t offsetof(struct ef4_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/ checksum ignored /\n \n \t/ Fill out payload /\ndiff --git a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c\nindex 8ec76329237a49..dc716feb79cb5a 100644\n--- a/drivers/net/ethernet/sfc/selftest.c\n+++ b/drivers/net/ethernet/sfc/selftest.c\n@@ -398,8 +398,8 @@ static void efx_iterate_state(struct efx_nic efx)\n \n \t/* Initialise udp header /\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(payload) -\n-\t\t\t\t offsetof(struct efx_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(payload) -\n+\t\t\t offsetof(struct efx_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/ checksum ignored /\n \n \t/ Fill out payload /\ndiff --git a/drivers/net/ethernet/sfc/siena/selftest.c b/drivers/net/ethernet/sfc/siena/selftest.c\nindex 930643612df511..c74cf51313643d 100644\n--- a/drivers/net/ethernet/sfc/siena/selftest.c\n+++ b/drivers/net/ethernet/sfc/siena/selftest.c\n@@ -399,8 +399,8 @@ static void efx_iterate_state(struct efx_nic efx)\n \n \t/* Initialise udp header /\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(payload) -\n-\t\t\t\t offsetof(struct efx_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(payload) -\n+\t\t\t offsetof(struct efx_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/ checksum ignored /\n \n \t/ Fill out payload /\ndiff --git a/drivers/net/ethernet/sfc/tc_encap_actions.c b/drivers/net/ethernet/sfc/tc_encap_actions.c\nindex db222abef53b2a..c2ad3a358d2012 100644\n--- a/drivers/net/ethernet/sfc/tc_encap_actions.c\n+++ b/drivers/net/ethernet/sfc/tc_encap_actions.c\n@@ -311,7 +311,7 @@ static void efx_gen_tun_header_udp(struct efx_tc_encap_action encap, u8 len)\n \tencap-\u003eencap_hdr_len += sizeof(udp);\n \n \tudp-\u003edest = key-\u003etp_dst;\n-\tudp-\u003elen = cpu_to_be16(sizeof(udp) + len);\n+\tudp_set_len_short(udp, sizeof(udp) + len);\n }\n \n static void efx_gen_tun_header_vxlan(struct efx_tc_encap_action encap)\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\nindex a0c75886587c35..29e824bd90ca6b 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\n@@ -154,9 +154,9 @@ static struct sk_buff stmmac_test_get_udp_skb(struct stmmac_priv priv,\n \t} else {\n \t\tuhdr-\u003esource = htons(attr-\u003esport);\n \t\tuhdr-\u003edest = htons(attr-\u003edport);\n-\t\tuhdr-\u003elen = htons(sizeof(shdr) + sizeof(uhdr) + attr-\u003esize);\n+\t\tudp_set_len_short(uhdr, sizeof(shdr) + sizeof(uhdr) + attr-\u003esize);\n \t\tif (attr-\u003emax_size)\n-\t\t\tuhdr-\u003elen = htons(attr-\u003emax_size -\n+\t\t\tudp_set_len_short(uhdr, attr-\u003emax_size -\n \t\t\t\t\t (sizeof(ihdr) + sizeof(ehdr)));\n \t\tuhdr-\u003echeck = 0;\n \t}\ndiff --git a/drivers/net/geneve.c b/drivers/net/geneve.c\nindex 396e1a113cd49e..a1639ad53077ec 100644\n--- a/drivers/net/geneve.c\n+++ b/drivers/net/geneve.c\n@@ -631,7 +631,7 @@ static int geneve_post_decap_hint(const struct sock sk, struct sk_buff skb,\n \n \t/* Adjust the nested UDP header len and checksum. /\n \tuh = udp_hdr(skb);\n-\tuh-\u003elen = htons(skb-\u003elen - gro_hint-\u003enested_tp_offset);\n+\tudp_set_len_short(uh, skb-\u003elen - gro_hint-\u003enested_tp_offset);\n \tif (uh-\u003echeck) {\n \t\tlen = skb-\u003elen - gro_hint-\u003enested_tp_offset;\n \t\tskb_shinfo(skb)-\u003egso_type \|= SKB_GSO_UDP_TUNNEL_CSUM;\n@@ -1745,6 +1745,8 @@ static void geneve_setup(struct net_device dev)\n \tdev-\u003emax_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev-\u003ehard_header_len;\n \n \tnetif_keep_dst(dev);\n+\tnetif_set_tso_max_size(dev, GSO_MAX_SIZE);\n+\n \tdev-\u003epriv_flags \u0026= ~IFF_TX_SKB_SHARING;\n \tdev-\u003epriv_flags \|= IFF_LIVE_ADDR_CHANGE \| IFF_NO_QUEUE;\n \tdev-\u003elltx = true;\ndiff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c\nindex c1812a98365b78..a531548eb89138 100644\n--- a/drivers/net/netconsole.c\n+++ b/drivers/net/netconsole.c\n@@ -1792,7 +1792,7 @@ static void push_udp(struct netpoll np, struct sk_buff skb, int len)\n \tudph = udp_hdr(skb);\n \tudph-\u003esource = htons(np-\u003elocal_port);\n \tudph-\u003edest = htons(np-\u003eremote_port);\n-\tudph-\u003elen = htons(udp_len);\n+\tudp_set_len_short(udph, udp_len);\n \n \tnetpoll_udp_checksum(np, skb, len);\n }\ndiff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c\nindex aed9ad5f1b43af..f65b4cf4ea392b 100644\n--- a/drivers/net/netdevsim/dev.c\n+++ b/drivers/net/netdevsim/dev.c\n@@ -845,7 +845,7 @@ static struct sk_buff nsim_dev_trap_skb_build(void)\n \tudph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);\n \tget_random_bytes(\u0026udph-\u003esource, sizeof(u16));\n \tget_random_bytes(\u0026udph-\u003edest, sizeof(u16));\n-\tudph-\u003elen = htons(sizeof(struct udphdr) + data_len);\n+\tudp_set_len_short(udph, sizeof(struct udphdr) + data_len);\n \n \treturn skb;\n }\ndiff --git a/drivers/net/netdevsim/psample.c b/drivers/net/netdevsim/psample.c\nindex 717d157c3ae2b6..1e71c3da4def52 100644\n--- a/drivers/net/netdevsim/psample.c\n+++ b/drivers/net/netdevsim/psample.c\n@@ -73,7 +73,7 @@ static struct sk_buff nsim_dev_psample_skb_build(void)\n \tudph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);\n \tget_random_bytes(\u0026udph-\u003esource, sizeof(u16));\n \tget_random_bytes(\u0026udph-\u003edest, sizeof(u16));\n-\tudph-\u003elen = htons(sizeof(struct udphdr) + data_len);\n+\tudp_set_len_short(udph, sizeof(struct udphdr) + data_len);\n \n \treturn skb;\n }\ndiff --git a/drivers/net/netdevsim/psp.c b/drivers/net/netdevsim/psp.c\nindex 59c990fdc79ecd..6b3532b5e360d5 100644\n--- a/drivers/net/netdevsim/psp.c\n+++ b/drivers/net/netdevsim/psp.c\n@@ -84,6 +84,7 @@ nsim_do_psp(struct sk_buff skb, struct netdevsim ns,\n \t\tstruct iphdr iph;\n \t\tstruct udphdr uh;\n \t\t__wsum csum;\n+\t\tint udplen;\n \n \t\t/* Do not decapsulate. Receive the skb with the udp and psp\n \t\t * headers still there as if this is a normal udp packet.\n@@ -91,19 +92,20 @@ nsim_do_psp(struct sk_buff skb, struct netdevsim ns,\n \t\t * provide a valid checksum here, so the skb isn't dropped.\n \t\t /\n \t\tuh = udp_hdr(skb);\n+\t\tudplen = udp_get_len(skb, uh, skb_transport_offset(skb));\n \t\tcsum = skb_checksum(skb, skb_transport_offset(skb),\n-\t\t\t\t ntohs(uh-\u003elen), 0);\n+\t\t\t\t udplen, 0);\n \n \t\tswitch (skb-\u003eprotocol) {\n \t\tcase htons(ETH_P_IP):\n \t\t\tiph = ip_hdr(skb);\n-\t\t\tuh-\u003echeck = udp_v4_check(ntohs(uh-\u003elen), iph-\u003esaddr,\n+\t\t\tuh-\u003echeck = udp_v4_check(udplen, iph-\u003esaddr,\n \t\t\t\t\t\t iph-\u003edaddr, csum);\n \t\t\tbreak;\n #if IS_ENABLED(CONFIG_IPV6)\n \t\tcase htons(ETH_P_IPV6):\n \t\t\tip6h = ipv6_hdr(skb);\n-\t\t\tuh-\u003echeck = udp_v6_check(ntohs(uh-\u003elen), \u0026ip6h-\u003esaddr,\n+\t\t\tuh-\u003echeck = udp_v6_check(udplen, \u0026ip6h-\u003esaddr,\n \t\t\t\t\t\t \u0026ip6h-\u003edaddr, csum);\n \t\t\tbreak;\n #endif\ndiff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c\nindex 67c367cc566233..3a32f067e701df 100644\n--- a/drivers/net/vxlan/vxlan_core.c\n+++ b/drivers/net/vxlan/vxlan_core.c\n@@ -3370,6 +3370,8 @@ static void vxlan_setup(struct net_device dev)\n \tdev-\u003emangleid_features = NETIF_F_GSO_PARTIAL;\n \n \tnetif_keep_dst(dev);\n+\tnetif_set_tso_max_size(dev, GSO_MAX_SIZE);\n+\n \tdev-\u003epriv_flags \|= IFF_NO_QUEUE;\n \tdev-\u003echange_proto_down = true;\n \tdev-\u003elltx = true;\ndiff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c\nindex eb8851113654f5..824bbefce61c78 100644\n--- a/drivers/net/wireguard/receive.c\n+++ b/drivers/net/wireguard/receive.c\n@@ -62,7 +62,7 @@ static int prepare_skb_header(struct sk_buff skb, struct wg_device wg)\n \t\t * to have UDP fields.\n \t\t /\n \t\treturn -EINVAL;\n-\tdata_len = ntohs(udp-\u003elen);\n+\tdata_len = udp_get_len_short(udp);\n \tif (unlikely(data_len \u003c sizeof(struct udphdr) \|\|\n \t\t data_len \u003e skb-\u003elen - data_offset))\n \t\t/ UDP packet is reporting too small of a size or lying about\ndiff --git a/include/linux/udp.h b/include/linux/udp.h\nindex ce56ebcee5cbcd..998906ec3b32ad 100644\n--- a/include/linux/udp.h\n+++ b/include/linux/udp.h\n@@ -23,6 +23,33 @@ static inline struct udphdr udp_hdr(const struct sk_buff skb)\n \treturn (struct udphdr )skb_transport_header(skb);\n }\n \n+static inline unsigned int udp_get_len(const struct sk_buff skb,\n+\t\t\t\t const struct udphdr uh,\n+\t\t\t\t unsigned int dataoff)\n+{\n+\tif (uh-\u003elen)\n+\t\treturn ntohs(uh-\u003elen);\n+\tif (skb_is_gso(skb)) / BIG TCP /\n+\t\treturn skb-\u003elen - dataoff;\n+\treturn 0;\n+}\n+\n+static inline unsigned int udp_get_len_short(const struct udphdr uh)\n+{\n+\treturn ntohs(uh-\u003elen);\n+}\n+\n+static inline void udp_set_len(struct udphdr uh, unsigned int len)\n+{\n+\tuh-\u003elen = len \u003c GRO_LEGACY_MAX_SIZE ? htons(len) : 0;\n+}\n+\n+static inline void udp_set_len_short(struct udphdr uh, unsigned int len)\n+{\n+\tDEBUG_NET_WARN_ON_ONCE(len \u003e= GRO_LEGACY_MAX_SIZE);\n+\tuh-\u003elen = htons(len);\n+}\n+\n #define UDP_HTABLE_SIZE_MIN_PERNET\t128\n #define UDP_HTABLE_SIZE_MIN\t\t(IS_ENABLED(CONFIG_BASE_SMALL) ? 128 : 256)\n #define UDP_HTABLE_SIZE_MAX\t\t65536\ndiff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h\nindex 31559796949a78..09ae115099dfe2 100644\n--- a/include/trace/events/icmp.h\n+++ b/include/trace/events/icmp.h\n@@ -44,7 +44,7 @@ TRACE_EVENT(icmp_send,\n \t\t\t} else {\n \t\t\t\t__entry-\u003esport = ntohs(uh-\u003esource);\n \t\t\t\t__entry-\u003edport = ntohs(uh-\u003edest);\n-\t\t\t\t__entry-\u003eulen = ntohs(uh-\u003elen);\n+\t\t\t\t__entry-\u003eulen = udp_get_len_short(uh);\n \t\t\t}\n \n \t\t\tp32 = (__be32 ) __entry-\u003esaddr;\ndiff --git a/lib/tests/blackhole_dev_kunit.c b/lib/tests/blackhole_dev_kunit.c\nindex 06834ab35f43c5..fa3e0533038d6f 100644\n--- a/lib/tests/blackhole_dev_kunit.c\n+++ b/lib/tests/blackhole_dev_kunit.c\n@@ -46,7 +46,7 @@ static void test_blackholedev(struct kunit test)\n \tuh = (struct udphdr )skb_push(skb, sizeof(struct udphdr));\n \tskb_set_transport_header(skb, 0);\n \tuh-\u003esource = uh-\u003edest = htons(UDP_PORT);\n-\tuh-\u003elen = htons(data_len);\n+\tudp_set_len_short(uh, data_len);\n \tuh-\u003echeck = 0;\n \t/ (Network) IPv6 /\n \tip6h = (struct ipv6hdr )skb_push(skb, sizeof(struct ipv6hdr));\ndiff --git a/net/6lowpan/nhc_udp.c b/net/6lowpan/nhc_udp.c\nindex 0a506c77283dde..ed4227e6db7442 100644\n--- a/net/6lowpan/nhc_udp.c\n+++ b/net/6lowpan/nhc_udp.c\n@@ -88,16 +88,16 @@ static int udp_uncompress(struct sk_buff skb, size_t needed)\n \tswitch (lowpan_dev(skb-\u003edev)-\u003elltype) {\n \tcase LOWPAN_LLTYPE_IEEE802154:\n \t\tif (lowpan_802154_cb(skb)-\u003ed_size)\n-\t\t\tuh.len = htons(lowpan_802154_cb(skb)-\u003ed_size -\n-\t\t\t\t sizeof(struct ipv6hdr));\n+\t\t\tudp_set_len_short(\u0026uh, lowpan_802154_cb(skb)-\u003ed_size -\n+\t\t\t\t\t sizeof(struct ipv6hdr));\n \t\telse\n-\t\t\tuh.len = htons(skb-\u003elen + sizeof(struct udphdr));\n+\t\t\tudp_set_len_short(\u0026uh, skb-\u003elen + sizeof(struct udphdr));\n \t\tbreak;\n \tdefault:\n-\t\tuh.len = htons(skb-\u003elen + sizeof(struct udphdr));\n+\t\tudp_set_len_short(\u0026uh, skb-\u003elen + sizeof(struct udphdr));\n \t\tbreak;\n \t}\n-\tpr_debug(\"uncompressed UDP length: src = %d\", ntohs(uh.len));\n+\tpr_debug(\"uncompressed UDP length: src = %d\", udp_get_len_short(\u0026uh));\n \n \t/ replace the compressed UDP head by the uncompressed UDP\n \t * header\ndiff --git a/net/core/pktgen.c b/net/core/pktgen.c\nindex 8e185b31828853..5b4dd04d612476 100644\n--- a/net/core/pktgen.c\n+++ b/net/core/pktgen.c\n@@ -3005,7 +3005,7 @@ static struct sk_buff fill_packet_ipv4(struct net_device odev,\n \n \tudph-\u003esource = htons(pkt_dev-\u003ecur_udp_src);\n \tudph-\u003edest = htons(pkt_dev-\u003ecur_udp_dst);\n-\tudph-\u003elen = htons(datalen + 8);\t/* DATA + udphdr /\n+\tudp_set_len_short(udph, datalen + 8);\t/ DATA + udphdr /\n \tudph-\u003echeck = 0;\n \n \tiph-\u003eihl = 5;\n@@ -3138,7 +3138,7 @@ static struct sk_buff fill_packet_ipv6(struct net_device odev,\n \tudplen = datalen + sizeof(struct udphdr);\n \tudph-\u003esource = htons(pkt_dev-\u003ecur_udp_src);\n \tudph-\u003edest = htons(pkt_dev-\u003ecur_udp_dst);\n-\tudph-\u003elen = htons(udplen);\n+\tudp_set_len_short(udph, udplen);\n \tudph-\u003echeck = 0;\n \n \t(__be32 ) iph = htonl(0x60000000);\t/ Version + flow /\ndiff --git a/net/core/selftests.c b/net/core/selftests.c\nindex 0a203d3fb9dcbe..36b949ae520b31 100644\n--- a/net/core/selftests.c\n+++ b/net/core/selftests.c\n@@ -72,9 +72,9 @@ struct sk_buff net_test_get_skb(struct net_device ndev, u8 id,\n \t} else {\n \t\tuhdr-\u003esource = htons(attr-\u003esport);\n \t\tuhdr-\u003edest = htons(attr-\u003edport);\n-\t\tuhdr-\u003elen = htons(sizeof(shdr) + sizeof(uhdr) + attr-\u003esize);\n+\t\tudp_set_len_short(uhdr, sizeof(shdr) + sizeof(uhdr) + attr-\u003esize);\n \t\tif (attr-\u003emax_size)\n-\t\t\tuhdr-\u003elen = htons(attr-\u003emax_size -\n+\t\t\tudp_set_len_short(uhdr, attr-\u003emax_size -\n \t\t\t\t\t (sizeof(ihdr) + sizeof(ehdr)));\n \t\tuhdr-\u003echeck = 0;\n \t}\ndiff --git a/net/core/skbuff.c b/net/core/skbuff.c\nindex 18dabb4e9cfa0e..6ae4c2b205f2ef 100644\n--- a/net/core/skbuff.c\n+++ b/net/core/skbuff.c\n@@ -4775,6 +4775,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb,\n \tstruct sk_buff tail = NULL;\n \tstruct sk_buff list_skb = skb_shinfo(head_skb)-\u003efrag_list;\n \tunsigned int mss = skb_shinfo(head_skb)-\u003egso_size;\n+\tbool gso_by_frags = mss == GSO_BY_FRAGS;\n \tunsigned int doffset = head_skb-\u003edata - skb_mac_header(head_skb);\n \tunsigned int offset = doffset;\n \tunsigned int tnl_hlen = skb_tnl_header_len(head_skb);\n@@ -4790,7 +4791,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb,\n \tint nfrags, pos;\n \n \tif ((skb_shinfo(head_skb)-\u003egso_type \u0026 SKB_GSO_DODGY) \u0026\u0026\n-\t mss != GSO_BY_FRAGS \u0026\u0026 mss != skb_headlen(head_skb)) {\n+\t !gso_by_frags \u0026\u0026 mss != skb_headlen(head_skb)) {\n \t\tstruct sk_buff check_skb;\n \n \t\tfor (check_skb = list_skb; check_skb; check_skb = check_skb-\u003enext) {\n@@ -4818,7 +4819,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb,\n \tsg = !!(features \u0026 NETIF_F_SG);\n \tcsum = !!can_checksum_protocol(features, proto);\n \n-\tif (sg \u0026\u0026 csum \u0026\u0026 (mss != GSO_BY_FRAGS)) {\n+\tif (sg \u0026\u0026 csum \u0026\u0026 !gso_by_frags) {\n \t\tif (!(features \u0026 NETIF_F_GSO_PARTIAL)) {\n \t\t\tstruct sk_buff iter;\n \t\t\tunsigned int frag_len;\n@@ -4852,9 +4853,8 @@ struct sk_buff skb_segment(struct sk_buff head_skb,\n \t\t/ GSO partial only requires that we trim off any excess that\n \t\t * doesn't fit into an MSS sized block, so take care of that\n \t\t * now.\n-\t\t * Cap len to not accidentally hit GSO_BY_FRAGS.\n \t\t /\n-\t\tpartial_segs = min(len, GSO_BY_FRAGS - 1) / mss;\n+\t\tpartial_segs = len / mss;\n \t\tif (partial_segs \u003e 1)\n \t\t\tmss = partial_segs;\n \t\telse\n@@ -4878,7 +4878,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb,\n \t\tint hsize;\n \t\tint size;\n \n-\t\tif (unlikely(mss == GSO_BY_FRAGS)) {\n+\t\tif (unlikely(gso_by_frags)) {\n \t\t\tlen = list_skb-\u003elen;\n \t\t} else {\n \t\t\tlen = head_skb-\u003elen - offset;\ndiff --git a/net/core/tso.c b/net/core/tso.c\nindex 347b3856ddb91f..d2934bcfa795f0 100644\n--- a/net/core/tso.c\n+++ b/net/core/tso.c\n@@ -39,7 +39,8 @@ void tso_build_hdr(const struct sk_buff skb, char hdr, struct tso_t tso,\n \t} else {\n \t\tstruct udphdr uh = (struct udphdr )hdr;\n \n-\t\tuh-\u003elen = htons(sizeof(uh) + size);\n+\t\t/* size is after segmentation. /\n+\t\tudp_set_len_short(uh, sizeof(uh) + size);\n \t}\n }\n EXPORT_SYMBOL(tso_build_hdr);\ndiff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c\nindex dfc81ee969ae03..a6c18aea7498d8 100644\n--- a/net/ipv4/esp4.c\n+++ b/net/ipv4/esp4.c\n@@ -323,7 +323,7 @@ static struct ip_esp_hdr esp_output_udp_encap(struct sk_buff skb,\n \tuh = (struct udphdr )esp-\u003eesph;\n \tuh-\u003esource = sport;\n \tuh-\u003edest = dport;\n-\tuh-\u003elen = htons(len);\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \t/ For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload\ndiff --git a/net/ipv4/fou_core.c b/net/ipv4/fou_core.c\nindex 865bd7205122d2..aef3ce1dec7aa2 100644\n--- a/net/ipv4/fou_core.c\n+++ b/net/ipv4/fou_core.c\n@@ -1040,7 +1040,7 @@ static void fou_build_udp(struct sk_buff skb, struct ip_tunnel_encap e,\n \n \tuh-\u003edest = e-\u003edport;\n \tuh-\u003esource = sport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \tudp_set_csum(!(e-\u003eflags \u0026 TUNNEL_ENCAP_FLAG_CSUM), skb,\n \t\t fl4-\u003esaddr, fl4-\u003edaddr, skb-\u003elen);\n \ndiff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c\nindex a35ffedacc7c7f..155db067eaecbe 100644\n--- a/net/ipv4/ipconfig.c\n+++ b/net/ipv4/ipconfig.c\n@@ -847,7 +847,7 @@ static void __init ic_bootp_send_if(struct ic_device d, unsigned long jiffies_d\n \t/ Construct UDP header /\n \tb-\u003eudph.source = htons(68);\n \tb-\u003eudph.dest = htons(67);\n-\tb-\u003eudph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr));\n+\tudp_set_len_short(\u0026b-\u003eudph, sizeof(struct bootp_pkt) - sizeof(struct iphdr));\n \t/ UDP checksum not calculated -- explicitly allowed in BOOTP RFC /\n \n \t/ Construct DHCP/BOOTP header /\n@@ -1025,10 +1025,10 @@ static int __init ic_bootp_recv(struct sk_buff skb, struct net_device dev, str\n \tif (b-\u003eudph.source != htons(67) \|\| b-\u003eudph.dest != htons(68))\n \t\tgoto drop;\n \n-\tif (ntohs(h-\u003etot_len) \u003c ntohs(b-\u003eudph.len) + sizeof(struct iphdr))\n+\tif (ntohs(h-\u003etot_len) \u003c udp_get_len_short(\u0026b-\u003eudph) + sizeof(struct iphdr))\n \t\tgoto drop;\n \n-\tlen = ntohs(b-\u003eudph.len) - sizeof(struct udphdr);\n+\tlen = udp_get_len_short(\u0026b-\u003eudph) - sizeof(struct udphdr);\n \text_len = len - (sizeof(b) -\n \t\t\t sizeof(struct iphdr) -\n \t\t\t sizeof(struct udphdr) -\ndiff --git a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\nindex e540b86bd15b6b..4492bc548a66bf 100644\n--- a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\n+++ b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\n@@ -127,7 +127,7 @@ static int snmp_translate(struct nf_conn ct, int dir, struct sk_buff skb)\n {\n \tstruct iphdr iph = ip_hdr(skb);\n \tstruct udphdr udph = (struct udphdr )((__be32 )iph + iph-\u003eihl);\n-\tu16 datalen = ntohs(udph-\u003elen) - sizeof(struct udphdr);\n+\tu16 datalen = udp_get_len_short(udph) - sizeof(struct udphdr);\n \tchar data = (unsigned char )udph + sizeof(struct udphdr);\n \tstruct snmp_ctx ctx;\n \tint ret;\n@@ -181,7 +181,7 @@ static int help(struct sk_buff skb, unsigned int protoff,\n \t enough room for a UDP header. Just verify the UDP length field so we\n \t * can mess around with the payload.\n \t /\n-\tif (ntohs(udph-\u003elen) != skb-\u003elen - (iph-\u003eihl \u003c\u003c 2)) {\n+\tif (udp_get_len_short(udph) != skb-\u003elen - (iph-\u003eihl \u003c\u003c 2)) {\n \t\tnf_ct_helper_log(skb, ct, \"dropping malformed packet\\n\");\n \t\treturn NF_DROP;\n \t}\ndiff --git a/net/ipv4/route.c b/net/ipv4/route.c\nindex 3f3de5164d6e58..0825ed9837146c 100644\n--- a/net/ipv4/route.c\n+++ b/net/ipv4/route.c\n@@ -3187,7 +3187,7 @@ static struct sk_buff inet_rtm_getroute_build_skb(__be32 src, __be32 dst,\n \t\tudph = skb_put_zero(skb, sizeof(struct udphdr));\n \t\tudph-\u003esource = sport;\n \t\tudph-\u003edest = dport;\n-\t\tudph-\u003elen = htons(sizeof(struct udphdr));\n+\t\tudp_set_len_short(udph, sizeof(struct udphdr));\n \t\tudph-\u003echeck = 0;\n \t\tbreak;\n \t}\ndiff --git a/net/ipv4/udp.c b/net/ipv4/udp.c\nindex 59248a59358ca5..2b9b55a147582b 100644\n--- a/net/ipv4/udp.c\n+++ b/net/ipv4/udp.c\n@@ -1108,7 +1108,8 @@ static int udp_send_skb(struct sk_buff skb, struct flowi4 fl4,\n \tuh = udp_hdr(skb);\n \tuh-\u003esource = inet_sk(sk)-\u003einet_sport;\n \tuh-\u003edest = fl4-\u003efl4_dport;\n-\tuh-\u003elen = htons(len);\n+\t/* Datagram length checked in udp_sendmsg. /\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \tif (cork-\u003egso_size) {\n@@ -2591,8 +2592,8 @@ int udp_rcv(struct sk_buff skb)\n \tstruct rtable rt = skb_rtable(skb);\n \tstruct net net = dev_net(skb-\u003edev);\n \tstruct sock sk = NULL;\n-\tunsigned short ulen;\n \t__be32 saddr, daddr;\n+\tunsigned int ulen;\n \tstruct udphdr uh;\n \tbool refcounted;\n \tint drop_reason;\n@@ -2606,7 +2607,7 @@ int udp_rcv(struct sk_buff skb)\n \t\tgoto drop;\t\t/ No space for header. /\n \n \tuh = udp_hdr(skb);\n-\tulen = ntohs(uh-\u003elen);\n+\tulen = udp_get_len(skb, uh, 0);\n \tsaddr = ip_hdr(skb)-\u003esaddr;\n \tdaddr = ip_hdr(skb)-\u003edaddr;\n \ndiff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c\nindex 29651b1a0bc704..8f77c8788f6db0 100644\n--- a/net/ipv4/udp_offload.c\n+++ b/net/ipv4/udp_offload.c\n@@ -279,11 +279,11 @@ static struct sk_buff __skb_udp_tunnel_segment(struct sk_buff skb,\n \t\t segment instead of the entire frame.\n \t\t /\n \t\tif (gso_partial \u0026\u0026 skb_is_gso(skb)) {\n-\t\t\tuh-\u003elen = htons(skb_shinfo(skb)-\u003egso_size +\n-\t\t\t\t\tSKB_GSO_CB(skb)-\u003edata_offset +\n-\t\t\t\t\tskb-\u003ehead - (unsigned char )uh);\n+\t\t\tudp_set_len_short(uh, skb_shinfo(skb)-\u003egso_size +\n+\t\t\t\t\t SKB_GSO_CB(skb)-\u003edata_offset +\n+\t\t\t\t\t skb-\u003ehead - (unsigned char )uh);\n \t\t} else {\n-\t\t\tuh-\u003elen = htons(len);\n+\t\t\tudp_set_len_short(uh, len);\n \t\t}\n \n \t\tif (!need_csum)\n@@ -468,7 +468,7 @@ static struct sk_buff __udp_gso_segment_list(struct sk_buff skb,\n \tif (IS_ERR(skb))\n \t\treturn skb;\n \n-\tudp_hdr(skb)-\u003elen = htons(sizeof(struct udphdr) + mss);\n+\tudp_set_len_short(udp_hdr(skb), sizeof(struct udphdr) + mss);\n \n \tif (is_ipv6)\n \t\treturn __udpv6_gso_segment_list_csum(skb);\n@@ -486,8 +486,8 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb,\n \tunsigned int mss;\n \tbool copy_dtor;\n \t__sum16 check;\n-\t__be16 newlen;\n \tint ret = 0;\n+\tu16 newlen;\n \n \tmss = skb_shinfo(gso_skb)-\u003egso_size;\n \tif (gso_skb-\u003elen \u003c= sizeof(uh) + mss)\n@@ -564,8 +564,8 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb,\n \t\t\t(skb_shinfo(gso_skb)-\u003etx_flags \u0026 SKBTX_ANY_TSTAMP);\n \n \t/* compute checksum adjustment based on old length versus new /\n-\tnewlen = htons(sizeof(uh) + mss);\n-\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), newlen);\n+\tnewlen = sizeof(uh) + mss;\n+\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), htons(newlen));\n \n \tfor (;;) {\n \t\tif (copy_dtor) {\n@@ -577,7 +577,7 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb,\n \t\tif (!seg-\u003enext)\n \t\t\tbreak;\n \n-\t\tuh-\u003elen = newlen;\n+\t\tudp_set_len_short(uh, newlen);\n \t\tuh-\u003echeck = check;\n \n \t\tif (seg-\u003eip_summed == CHECKSUM_PARTIAL)\n@@ -594,11 +594,10 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb,\n \t segment may not be full MSS, account for that in the checksum\n \t /\n \tif (!skb_is_gso(seg))\n-\t\tnewlen = htons(skb_tail_pointer(seg) -\n-\t\t\t skb_transport_header(seg) + seg-\u003edata_len);\n-\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), newlen);\n+\t\tnewlen = skb_tail_pointer(seg) - skb_transport_header(seg) + seg-\u003edata_len;\n+\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), htons(newlen));\n \n-\tuh-\u003elen = newlen;\n+\tudp_set_len_short(uh, newlen);\n \tuh-\u003echeck = check;\n \n \tif (seg-\u003eip_summed == CHECKSUM_PARTIAL)\n@@ -708,12 +707,8 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head,\n \t\treturn NULL;\n \t}\n \n-\t/ Do not deal with padded or malicious packets, sorry ! /\n-\tulen = ntohs(uh-\u003elen);\n-\tif (ulen \u003c= sizeof(uh) \|\| ulen != skb_gro_len(skb)) {\n-\t\tNAPI_GRO_CB(skb)-\u003eflush = 1;\n-\t\treturn NULL;\n-\t}\n+\tulen = udp_get_len_short(uh);\n+\n \t/* pull encapsulating udp header /\n \tskb_gro_pull(skb, sizeof(struct udphdr));\n \n@@ -742,7 +737,7 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head,\n \t\t On len mismatch merge the first packet shorter than gso_size,\n \t\t * otherwise complete the GRO packet.\n \t\t /\n-\t\tif (ulen \u003e ntohs(uh2-\u003elen) \|\| flush) {\n+\t\tif (ulen \u003e udp_get_len_short(uh2) \|\| flush) {\n \t\t\tpp = p;\n \t\t} else {\n \t\t\tif (NAPI_GRO_CB(skb)-\u003eis_flist) {\n@@ -765,7 +760,7 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head,\n \t\t\t}\n \t\t}\n \n-\t\tif (ret \|\| ulen != ntohs(uh2-\u003elen) \|\|\n+\t\tif (ret \|\| ulen != udp_get_len_short(uh2) \|\|\n \t\t NAPI_GRO_CB(p)-\u003ecount \u003e= UDP_GRO_CNT_MAX)\n \t\t\tpp = p;\n \n@@ -783,8 +778,14 @@ struct sk_buff udp_gro_receive(struct list_head head, struct sk_buff skb,\n \tstruct sk_buff p;\n \tstruct udphdr uh2;\n \tunsigned int off = skb_gro_offset(skb);\n+\tunsigned int ulen;\n \tint flush = 1;\n \n+\t/* Do not deal with padded or malicious packets, sorry! /\n+\tulen = udp_get_len_short(uh);\n+\tif (ulen \u003c= sizeof(uh) \|\| ulen != skb_gro_len(skb))\n+\t\tgoto out;\n+\n \t/* We can do L4 aggregation only if the packet can't land in a tunnel\n \t * otherwise we could corrupt the inner stream. Detecting such packets\n \t * cannot be foolproof and the aggregation might still happen in some\n@@ -915,12 +916,12 @@ static int udp_gro_complete_segment(struct sk_buff skb)\n int udp_gro_complete(struct sk_buff skb, int nhoff,\n \t\t udp_lookup_t lookup)\n {\n-\t__be16 newlen = htons(skb-\u003elen - nhoff);\n \tstruct udphdr uh = (struct udphdr )(skb-\u003edata + nhoff);\n+\tunsigned int newlen = skb-\u003elen - nhoff;\n \tstruct sock sk;\n \tint err;\n \n-\tuh-\u003elen = newlen;\n+\tudp_set_len(uh, newlen);\n \n \tsk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,\n \t\t\t\tudp4_lib_lookup_skb, skb, uh-\u003esource, uh-\u003edest);\n@@ -957,7 +958,7 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff skb, int nhoff)\n \n \t/* do fraglist only if there is no outer UDP encap (or we already processed it) /\n \tif (NAPI_GRO_CB(skb)-\u003eis_flist \u0026\u0026 !NAPI_GRO_CB(skb)-\u003eencap_mark) {\n-\t\tuh-\u003elen = htons(skb-\u003elen - nhoff);\n+\t\tudp_set_len(uh, skb-\u003elen - nhoff);\n \n \t\tskb_shinfo(skb)-\u003egso_type \|= (SKB_GSO_FRAGLIST\|SKB_GSO_UDP_L4);\n \t\tskb_shinfo(skb)-\u003egso_segs = NAPI_GRO_CB(skb)-\u003ecount;\ndiff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c\nindex 9ab3728f9630bf..a128fe85620d30 100644\n--- a/net/ipv4/udp_tunnel_core.c\n+++ b/net/ipv4/udp_tunnel_core.c\n@@ -178,7 +178,7 @@ void udp_tunnel_xmit_skb(struct rtable rt, struct sock sk, struct sk_buff skb\n \n \tuh-\u003edest = dst_port;\n \tuh-\u003esource = src_port;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \n \tmemset(\u0026(IPCB(skb)-\u003eopt), 0, sizeof(IPCB(skb)-\u003eopt));\n \ndiff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c\nindex 296b57926abb98..72ec0d7d112090 100644\n--- a/net/ipv6/esp6.c\n+++ b/net/ipv6/esp6.c\n@@ -230,7 +230,8 @@ static void esp_output_encap_csum(struct sk_buff skb)\n \tif (skb_mac_header(skb) == IPPROTO_UDP) {\n \t\tstruct udphdr uh = udp_hdr(skb);\n \t\tstruct ipv6hdr ip6h = ipv6_hdr(skb);\n-\t\tint len = ntohs(uh-\u003elen);\n+\t\t/* esp6_output_udp_encap limits len to U16_MAX. /\n+\t\tint len = udp_get_len_short(uh);\n \t\tunsigned int offset = skb_transport_offset(skb);\n \t\t__wsum csum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n \n@@ -358,7 +359,7 @@ static struct ip_esp_hdr esp6_output_udp_encap(struct sk_buff skb,\n \tuh = (struct udphdr )esp-\u003eesph;\n \tuh-\u003esource = sport;\n \tuh-\u003edest = dport;\n-\tuh-\u003elen = htons(len);\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \tskb_mac_header(skb) = IPPROTO_UDP;\ndiff --git a/net/ipv6/fou6.c b/net/ipv6/fou6.c\nindex 157765259e2f5f..4b659ca60ba9a8 100644\n--- a/net/ipv6/fou6.c\n+++ b/net/ipv6/fou6.c\n@@ -30,7 +30,7 @@ static void fou6_build_udp(struct sk_buff skb, struct ip_tunnel_encap e,\n \n \tuh-\u003edest = e-\u003edport;\n \tuh-\u003esource = sport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \tudp6_set_csum(!(e-\u003eflags \u0026 TUNNEL_ENCAP_FLAG_CSUM6), skb,\n \t\t \u0026fl6-\u003esaddr, \u0026fl6-\u003edaddr, skb-\u003elen);\n \ndiff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c\nindex 9adb5775487fac..32525a051a6f08 100644\n--- a/net/ipv6/ip6_udp_tunnel.c\n+++ b/net/ipv6/ip6_udp_tunnel.c\n@@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry dst, struct sock sk,\n \tuh-\u003edest = dst_port;\n \tuh-\u003esource = src_port;\n \n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \n \tskb_dst_set(skb, dst);\n \ndiff --git a/net/ipv6/udp.c b/net/ipv6/udp.c\nindex 392e18b9704544..02272466f4c298 100644\n--- a/net/ipv6/udp.c\n+++ b/net/ipv6/udp.c\n@@ -1081,12 +1081,12 @@ INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff skb)\n \tdaddr = \u0026ipv6_hdr(skb)-\u003edaddr;\n \tuh = udp_hdr(skb);\n \n-\tulen = ntohs(uh-\u003elen);\n+\tulen = udp_get_len(skb, uh, 0);\n \tif (ulen \u003e skb-\u003elen)\n \t\tgoto short_packet;\n \n \t/* Check for jumbo payload /\n-\tif (ulen == 0)\n+\tif (ulen == 0 \u0026\u0026 inet6_is_jumbogram(skb))\n \t\tulen = skb-\u003elen;\n \n \tif (ulen \u003c sizeof(uh))\n@@ -1369,7 +1369,8 @@ static int udp_v6_send_skb(struct sk_buff skb, struct flowi6 fl6,\n \tuh = udp_hdr(skb);\n \tuh-\u003esource = fl6-\u003efl6_sport;\n \tuh-\u003edest = fl6-\u003efl6_dport;\n-\tuh-\u003elen = htons(len);\n+\t/* Datagram length checked in udpv6_sendmsg. /\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \tif (cork-\u003egso_size) {\ndiff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c\nindex 778afc7453ce53..7370bcb80332ea 100644\n--- a/net/ipv6/udp_offload.c\n+++ b/net/ipv6/udp_offload.c\n@@ -171,7 +171,7 @@ int udp6_gro_complete(struct sk_buff skb, int nhoff)\n \n \t/* do fraglist only if there is no outer UDP encap (or we already processed it) /\n \tif (NAPI_GRO_CB(skb)-\u003eis_flist \u0026\u0026 !NAPI_GRO_CB(skb)-\u003eencap_mark) {\n-\t\tuh-\u003elen = htons(skb-\u003elen - nhoff);\n+\t\tudp_set_len(uh, skb-\u003elen - nhoff);\n \n \t\tskb_shinfo(skb)-\u003egso_type \|= (SKB_GSO_FRAGLIST\|SKB_GSO_UDP_L4);\n \t\tskb_shinfo(skb)-\u003egso_segs = NAPI_GRO_CB(skb)-\u003ecount;\ndiff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c\nindex f940914959b18e..4712cc41881a30 100644\n--- a/net/l2tp/l2tp_core.c\n+++ b/net/l2tp/l2tp_core.c\n@@ -1296,7 +1296,7 @@ static int l2tp_xmit_core(struct l2tp_session session, struct sk_buff skb, uns\n \t\t\tret = NET_XMIT_DROP;\n \t\t\tgoto out_unlock;\n \t\t}\n-\t\tuh-\u003elen = htons(udp_len);\n+\t\tudp_set_len_short(uh, udp_len);\n \n \t\t/ Calculate UDP checksum if configured to do so /\n #if IS_ENABLED(CONFIG_IPV6)\ndiff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c\nindex ce542ed4b013c8..c51ebd83a476fe 100644\n--- a/net/netfilter/ipvs/ip_vs_xmit.c\n+++ b/net/netfilter/ipvs/ip_vs_xmit.c\n@@ -1100,7 +1100,7 @@ ipvs_gue_encap(struct net net, struct sk_buff skb,\n \tdport = cp-\u003edest-\u003etun_port;\n \tudph-\u003edest = dport;\n \tudph-\u003esource = sport;\n-\tudph-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(udph, skb-\u003elen);\n \tudph-\u003echeck = 0;\n \n \tnext_protocol = IPPROTO_UDP;\ndiff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c\nindex cc9b7e5e19358d..a7edfefd6fd14b 100644\n--- a/net/netfilter/nf_conntrack_proto_udp.c\n+++ b/net/netfilter/nf_conntrack_proto_udp.c\n@@ -41,11 +41,22 @@ static void udp_error_log(const struct sk_buff skb,\n \tnf_l4proto_log_invalid(skb, state, IPPROTO_UDP, \"%s\", msg);\n }\n \n+static bool udp_validate_len(struct sk_buff skb,\n+\t\t\t const struct udphdr hdr,\n+\t\t\t unsigned int dataoff)\n+{\n+\tunsigned int udplen = udp_get_len(skb, hdr, dataoff);\n+\tunsigned int skblen = skb-\u003elen - dataoff;\n+\n+\tif (udplen \u003e skblen \|\| udplen \u003c sizeof(hdr))\n+\t\treturn false;\n+\treturn true;\n+}\n+\n static bool udp_error(struct sk_buff skb,\n \t\t unsigned int dataoff,\n \t\t const struct nf_hook_state state)\n {\n-\tunsigned int udplen = skb-\u003elen - dataoff;\n \tconst struct udphdr hdr;\n \tstruct udphdr _hdr;\n \n@@ -57,7 +68,7 @@ static bool udp_error(struct sk_buff skb,\n \t}\n \n \t/* Truncated/malformed packets /\n-\tif (ntohs(hdr-\u003elen) \u003e udplen \|\| ntohs(hdr-\u003elen) \u003c sizeof(hdr)) {\n+\tif (!udp_validate_len(skb, hdr, dataoff)) {\n \t\tudp_error_log(skb, state, \"truncated/malformed packet\");\n \t\treturn true;\n \t}\ndiff --git a/net/netfilter/nf_log_syslog.c b/net/netfilter/nf_log_syslog.c\nindex e37b09b3203b75..71dff0eb672c43 100644\n--- a/net/netfilter/nf_log_syslog.c\n+++ b/net/netfilter/nf_log_syslog.c\n@@ -301,7 +301,7 @@ nf_log_dump_udp_header(struct nf_log_buf m,\n \n \t/ Max length: 20 \"SPT=65535 DPT=65535 \" /\n \tnf_log_buf_add(m, \"SPT=%u DPT=%u LEN=%u \",\n-\t\t ntohs(uh-\u003esource), ntohs(uh-\u003edest), ntohs(uh-\u003elen));\n+\t\t ntohs(uh-\u003esource), ntohs(uh-\u003edest), udp_get_len_short(uh));\n \n out:\n \treturn 0;\ndiff --git a/net/netfilter/nf_nat_helper.c b/net/netfilter/nf_nat_helper.c\nindex bf591e6af0051a..3853f41db49953 100644\n--- a/net/netfilter/nf_nat_helper.c\n+++ b/net/netfilter/nf_nat_helper.c\n@@ -161,7 +161,7 @@ nf_nat_mangle_udp_packet(struct sk_buff skb,\n \n \t/* update the length of the UDP packet /\n \tdatalen = skb-\u003elen - protoff;\n-\tudph-\u003elen = htons(datalen);\n+\tudp_set_len_short(udph, datalen);\n \n \t/ fix udp checksum if udp checksum was previously calculated /\n \tif (!udph-\u003echeck \u0026\u0026 skb-\u003eip_summed != CHECKSUM_PARTIAL)\ndiff --git a/net/psp/psp_main.c b/net/psp/psp_main.c\nindex 8b2f178e317cb8..c9c1a8826b7f92 100644\n--- a/net/psp/psp_main.c\n+++ b/net/psp/psp_main.c\n@@ -231,7 +231,7 @@ static void psp_write_headers(struct net net, struct sk_buff skb, __be32 spi,\n \t\tuh-\u003esource = udp_flow_src_port(net, skb, 0, 0, false);\n \t}\n \tuh-\u003echeck = 0;\n-\tuh-\u003elen = htons(udp_len);\n+\tudp_set_len(uh, udp_len);\n \n \tpsph-\u003enexthdr = IPPROTO_TCP;\n \tpsph-\u003ehdrlen = PSP_HDRLEN_NOOPT;\ndiff --git a/net/sched/act_csum.c b/net/sched/act_csum.c\nindex 078d3a27130b8d..5fff52a8ca90dc 100644\n--- a/net/sched/act_csum.c\n+++ b/net/sched/act_csum.c\n@@ -276,7 +276,7 @@ static int tcf_csum_ipv4_udp(struct sk_buff skb, unsigned int ihl,\n \t\treturn 0;\n \n \tiph = ip_hdr(skb);\n-\tul = ntohs(udph-\u003elen);\n+\tul = udp_get_len_short(udph);\n \n \tif (udplite \|\| udph-\u003echeck) {\n \n@@ -334,7 +334,7 @@ static int tcf_csum_ipv6_udp(struct sk_buff skb, unsigned int ihl,\n \t\treturn 0;\n \n \tip6h = ipv6_hdr(skb);\n-\tul = ntohs(udph-\u003elen);\n+\tul = udp_get_len_short(udph);\n \n \tudph-\u003echeck = 0;\n \ndiff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c\nindex 458931062a04ef..906458f3d8c525 100644\n--- a/net/xfrm/xfrm_nat_keepalive.c\n+++ b/net/xfrm/xfrm_nat_keepalive.c\n@@ -133,7 +133,7 @@ static void nat_keepalive_send(struct nat_keepalive ka)\n \tuh = skb_push(skb, sizeof(*uh));\n \tuh-\u003esource = ka-\u003eencap_sport;\n \tuh-\u003edest = ka-\u003eencap_dport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len_short(uh, skb-\u003elen);\n \tuh-\u003echeck = 0;\n \n \tskb-\u003emark = ka-\u003esmark;\ndiff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile\nindex 708d960ae07d5b..4cb0a0bc1eeace 100644\n--- a/tools/testing/selftests/net/Makefile\n+++ b/tools/testing/selftests/net/Makefile\n@@ -13,6 +13,7 @@ TEST_PROGS := \\\n \tarp_ndisc_untracked_subnets.sh \\\n \tbareudp.sh \\\n \tbig_tcp.sh \\\n+\tbig_tcp_tunnels.sh \\\n \tbind_bhash.sh \\\n \tbpf_offload.py \\\n \tbridge_stp_mode.sh \\\ndiff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh\nnew file mode 100755\nindex 00000000000000..128a710e74ad5a\n--- /dev/null\n+++ b/tools/testing/selftests/net/big_tcp_tunnels.sh\n@@ -0,0 +1,183 @@\n+#!/usr/bin/env bash\n+# SPDX-License-Identifier: GPL-2.0\n+#\n+# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.\n+\n+SERVER_NS=$(mktemp -u server-XXXXXXXX)\n+SERVER_IP4=\"192.168.1.1\"\n+SERVER_IP6=\"2001:db8::1:1\"\n+SERVER_IP4_TUN=\"192.168.2.1\"\n+SERVER_IP6_TUN=\"2001:db8::2:1\"\n+\n+CLIENT_NS=$(mktemp -u client-XXXXXXXX)\n+CLIENT_IP4=\"192.168.1.2\"\n+CLIENT_IP6=\"2001:db8::1:2\"\n+CLIENT_IP4_TUN=\"192.168.2.2\"\n+CLIENT_IP6_TUN=\"2001:db8::2:2\"\n+\n+: \"${PACKETS_THRESHOLD:=1000}\"\n+\n+# Kselftest framework requirement - SKIP code is 4.\n+ksft_skip=4\n+\n+setup() {\n+\tip netns add \"$SERVER_NS\"\n+\tip netns add \"$CLIENT_NS\"\n+\tip -netns \"$SERVER_NS\" link add link1 type veth peer name link0 netns \"$CLIENT_NS\"\n+\n+\tip -netns \"$CLIENT_NS\" link set link0 up\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP4/24\" dev link0\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP6/112\" dev link0 nodad\n+\tip -netns \"$CLIENT_NS\" link set link0 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\tip -netns \"$SERVER_NS\" link set link1 up\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP4/24\" dev link1\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP6/112\" dev link1 nodad\n+\tip -netns \"$SERVER_NS\" link set link1 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\n+\tip netns exec \"$SERVER_NS\" netserver \u003e/dev/null\n+}\n+\n+setup_tunnel() {\n+\tif [ \"$2\" = 4 ]; then\n+\t\tSERVER_IP=\"$SERVER_IP4\"\n+\t\tCLIENT_IP=\"$CLIENT_IP4\"\n+\t\techo \"Setting up ${1^^} over IPv4, veth tx csum offload $3\"\n+\telse\n+\t\tSERVER_IP=\"$SERVER_IP6\"\n+\t\tCLIENT_IP=\"$CLIENT_IP6\"\n+\t\techo \"Setting up ${1^^} over IPv6, veth tx csum offload $3\"\n+\tfi\n+\n+\tif [ \"$1\" = vxlan ]; then\n+\t\tip -netns \"$CLIENT_NS\" link add tun0 type vxlan \\\n+\t\t\tid 5001 remote \"$SERVER_IP\" local \"$CLIENT_IP\" dev link0 dstport 4789\n+\telse\n+\t\tip -netns \"$CLIENT_NS\" link add tun0 type geneve \\\n+\t\t\tid 5001 remote \"$SERVER_IP\"\n+\tfi\n+\tip -netns \"$CLIENT_NS\" link set tun0 up\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP4_TUN/24\" dev tun0\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP6_TUN/112\" dev tun0 nodad\n+\tip -netns \"$CLIENT_NS\" link set tun0 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\tif [ \"$1\" = vxlan ]; then\n+\t\tip -netns \"$SERVER_NS\" link add tun1 type vxlan \\\n+\t\t\tid 5001 remote \"$CLIENT_IP\" local \"$SERVER_IP\" dev link1 dstport 4789\n+\telse\n+\t\tip -netns \"$SERVER_NS\" link add tun1 type geneve \\\n+\t\t\tid 5001 remote \"$CLIENT_IP\"\n+\tfi\n+\tip -netns \"$SERVER_NS\" link set tun1 up\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP4_TUN/24\" dev tun1\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP6_TUN/112\" dev tun1 nodad\n+\tip -netns \"$SERVER_NS\" link set tun1 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\n+\tip netns exec \"$CLIENT_NS\" ethtool -K link0 tx-checksumming \"$3\" \u003e /dev/null\n+\tip netns exec \"$SERVER_NS\" ethtool -K link1 tx-checksumming \"$3\" \u003e /dev/null\n+}\n+\n+cleanup_tunnel() {\n+\tip -netns \"$CLIENT_NS\" link del tun0\n+\tip -netns \"$SERVER_NS\" link del tun1\n+}\n+\n+cleanup() {\n+\tip netns pids \"$SERVER_NS\" \| xargs -r kill\n+\tip netns pids \"$CLIENT_NS\" \| xargs -r kill\n+\tip netns del \"$SERVER_NS\"\n+\tip netns del \"$CLIENT_NS\"\n+\trm -rf \"$WORKDIR\"\n+}\n+\n+do_test() {\n+\t# When tx csum offload is off, software GSO is performed before passing the\n+\t# packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify\n+\t# the software checksum path: if the checksum code is broken, these packets\n+\t# will be dropped.\n+\tif [ \"$2\" = on ]; then\n+\t\tCAPTURE_IFACE='link'\n+\telse\n+\t\tCAPTURE_IFACE='tun'\n+\tfi\n+\n+\tip netns exec \"$SERVER_NS\" tcpdump -nn -s 256 -i \"${CAPTURE_IFACE}1\" greater 65536 -w \"$WORKDIR/server.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_SERVER_PID=\"$!\"\n+\tip netns exec \"$CLIENT_NS\" tcpdump -nn -s 256 -i \"${CAPTURE_IFACE}0\" greater 65536 -w \"$WORKDIR/client.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_CLIENT_PID=\"$!\"\n+\n+\t# This filter doesn't capture all possible variants of SACK, but it's aimed\n+\t# at the typical one where SACK follows after [nop, nop, timestamp, nop,\n+\t# nop] (14 bytes after the 20-byte TCP header). IPv6 needs a separate match,\n+\t# because man tcpdump says:\n+\t# \u003e Arithmetic expression against transport layer headers, like tcp[0], does\n+\t# \u003e not work against IPv6 packets. It only looks at IPv4 packets.\n+\tip netns exec \"$SERVER_NS\" tcpdump -nn -s 256 -i \"tun1\" '(tcp[tcpflags] \u0026 (tcp-syn\|tcp-ack) = tcp-ack and tcp[34:2] \u0026 0xffc3 = 0x0502) or (ip6[6] = 0x06 and ip6[53] \u0026 0x12 = 0x10 and ip6[74:2] \u0026 0xffc3 = 0x0502)' -w \"$WORKDIR/sack.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_SACK_PID=\"$!\"\n+\n+\tif [ \"$1\" = 4 ]; then\n+\t\tSERVER_IP=\"$SERVER_IP4_TUN\"\n+\t\techo \"Running IPv4 traffic in the tunnel\"\n+\telse\n+\t\tSERVER_IP=\"$SERVER_IP6_TUN\"\n+\t\techo \"Running IPv6 traffic in the tunnel\"\n+\tfi\n+\n+\tsleep 1 # Give tcpdump a second to spin up.\n+\tip netns exec \"$CLIENT_NS\" netperf -t TCP_STREAM -l 5 -H \"$SERVER_IP\" -- \\\n+\t\t-m 80000 \u003e /dev/null\n+\tsleep 1 # Give tcpdump a second to process buffered packets.\n+\tkill \"$TCPDUMP_SERVER_PID\" \"$TCPDUMP_CLIENT_PID\" \"$TCPDUMP_SACK_PID\"\n+\twait \"$TCPDUMP_SERVER_PID\" \"$TCPDUMP_CLIENT_PID\" \"$TCPDUMP_SACK_PID\"\n+\tPACKETS_SERVER=$(tcpdump --count -r \"$WORKDIR/server.pcap\" 2\u003e /dev/null \| cut -d ' ' -f 1)\n+\tPACKETS_CLIENT=$(tcpdump --count -r \"$WORKDIR/client.pcap\" 2\u003e /dev/null \| cut -d ' ' -f 1)\n+\tPACKETS_SACK=$(tcpdump --count -r \"$WORKDIR/sack.pcap\" 2\u003e /dev/null \| cut -d ' ' -f 1)\n+\n+\techo \"Captured BIG TCP RX packets: $PACKETS_SERVER\"\n+\techo \"Captured BIG TCP TX packets: $PACKETS_CLIENT\"\n+\techo \"Captured TCP SACK packets: $PACKETS_SACK\"\n+\t[ \"$PACKETS_SERVER\" -gt \"$PACKETS_THRESHOLD\" ] \|\| return 1\n+\t[ \"$PACKETS_CLIENT\" -gt \"$PACKETS_THRESHOLD\" ] \|\| return 1\n+\t[ \"$PACKETS_SACK\" -lt \"$(( PACKETS_CLIENT / 2 ))\" ] \|\| return 1\n+}\n+\n+if ! netperf -V \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without netperf tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! tcpdump --version \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without tcpdump tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! ethtool --version \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without ethtool tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! ip link help 2\u003e\u00261 \| grep gso_ipv4_max_size \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+WORKDIR=$(mktemp -d)\n+trap cleanup EXIT\n+setup\n+for tunnel in vxlan geneve; do\n+\tfor tun_family in 4 6; do\n+\t\tfor traffic_family in 4 6; do\n+\t\t\tfor csum_offload in on off; do\n+\t\t\t\tsetup_tunnel \"$tunnel\" \"$tun_family\" \"$csum_offload\" \|\| exit \"$?\"\n+\t\t\t\tdo_test \"$traffic_family\" \"$csum_offload\" \|\| exit \"$?\"\n+\t\t\t\tcleanup_tunnel\n+\t\t\tdone\n+\t\tdone\n+\tdone\n+done\n" }
2/1	2026/07/07 02:47	agent	patch-evaluator	29m Model: gemini-3.1-pro-preview Args: null Results: { "EnableConfigs": [ "VXLAN", "GENEVE", "NET_FOU", "INET_ESP", "INET6_ESP", "L2TP", "IP_VS", "AMT", "WIREGUARD", "6LOWPAN_NHC_UDP", "NF_NAT_SNMP_BASIC", "NET_ACT_CSUM", "RDMA_RXE", "NETDEVSIM", "INET_PSP" ], "FocusSymbols": [ "__udp_gso_segment", "udp_gro_complete", "udp4_gro_complete", "udp6_gro_complete", "udp_tunnel_xmit_skb", "udp_tunnel6_xmit_skb", "__skb_udp_tunnel_segment", "udp_gro_receive_segment", "fou_build_udp", "fou6_build_udp", "esp_output_udp_encap", "esp6_output_udp_encap", "l2tp_xmit_core", "ipvs_gue_encap", "tso_build_hdr", "skb_segment", "amt_send_discovery", "nsim_do_psp", "psp_write_headers", "nat_keepalive_send", "tcf_csum_ipv4_udp", "tcf_csum_ipv6_udp", "nf_nat_mangle_udp_packet", "udp_error", "snmp_translate", "udp_uncompress", "prepare_skb_header", "rdma_build_skb", "rxe_udp_encap_recv", "efx_gen_tun_header_udp", "i40e_tso", "iavf_tso", "ice_tso", "idpf_tso", "otx2_sqe_add_ext", "mlx5e_shampo_update_ipv4_udp_hdr", "mlx5e_shampo_update_ipv6_udp_hdr", "inet_rtm_getroute_build_skb", "fill_packet_ipv4", "fill_packet_ipv6" ], "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.", "WorthFuzzing": true } Instruction: You are an expert Linux kernel maintainer. Your job is to review a provided patch series and determine if it makes functional changes to the kernel that should be fuzzed. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively use your code access tools to examine the actual source code and confirm any assumptions. Return WorthFuzzing=false if the patch only contains: - Modifications to Documentation/, Kconfig files, or code comments. - Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints. - Changes to numeric constants or macros that do not functionally alter execution flow. - Code paths that are impossible to reach in virtualized environments like GCE or QEMU, even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim). If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true. When returning WorthFuzzing=true, you MUST ALSO: 1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols. Avoid listing generic hot-path functions to prevent skewed test distributions. 2. Identify any specific CONFIG_ options required to properly test this new/modified feature. Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions. Do not list too generic configs (we already have them enabled). Only list those that specifically cover the modified code. List them in the EnableConfigs output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4"). Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: For your convenience, here is the diff of the changes: commit a82ad991569e9e2986e7c0d714f5587f5ee69273 Author: syz-cluster <triage@syzkaller.com> Date: Tue Jul 7 02:47:49 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/infiniband/core/lag.c b/drivers/infiniband/core/lag.c index 8fd80adfe833e7..00fe241737ffee 100644 --- a/drivers/infiniband/core/lag.c +++ b/drivers/infiniband/core/lag.c @@ -36,7 +36,7 @@ static struct sk_buff rdma_build_skb(struct net_device netdev, uh->source = htons(rdma_flow_label_to_udp_sport(ah_attr->grh.flow_label)); uh->dest = htons(ROCE_V2_UDP_DPORT); - uh->len = htons(sizeof(struct udphdr)); + udp_set_len_short(uh, sizeof(struct udphdr)); if (is_ipv4) { skb_push(skb, sizeof(struct iphdr)); diff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c index 3741b2c4b0bbfd..53daaf4c1eb2e0 100644 --- a/drivers/infiniband/sw/rxe/rxe_net.c +++ b/drivers/infiniband/sw/rxe/rxe_net.c @@ -242,7 +242,7 @@ static int rxe_udp_encap_recv(struct sock sk, struct sk_buff skb) pkt->port_num = 1; pkt->hdr = (u8 )(udph + 1); pkt->mask = RXE_GRH_MASK; - pkt->paylen = be16_to_cpu(udph->len) - sizeof(udph); + pkt->paylen = udp_get_len_short(udph) - sizeof(udph); / remove udp header / skb_pull(skb, sizeof(struct udphdr)); @@ -305,7 +305,7 @@ static void prepare_udp_hdr(struct sk_buff skb, __be16 src_port, udph->dest = dst_port; udph->source = src_port; - udph->len = htons(skb->len); + udp_set_len_short(udph, skb->len); udph->check = 0; } diff --git a/drivers/net/amt.c b/drivers/net/amt.c index 5cf97c65576fc2..a44ffbb1816523 100644 --- a/drivers/net/amt.c +++ b/drivers/net/amt.c @@ -667,7 +667,7 @@ static void amt_send_discovery(struct amt_dev amt) udph = udp_hdr(skb); udph->source = amt->gw_port; udph->dest = amt->relay_port; - udph->len = htons(sizeof(udph) + sizeof(amtd)); + udp_set_len_short(udph, sizeof(udph) + sizeof(amtd)); udph->check = 0; offset = skb_transport_offset(skb); skb->csum = skb_checksum(skb, offset, skb->len - offset, 0); @@ -760,7 +760,7 @@ static void amt_send_request(struct amt_dev amt, bool v6) udph = udp_hdr(skb); udph->source = amt->gw_port; udph->dest = amt->relay_port; - udph->len = htons(sizeof(amtrh) + sizeof(udph)); + udp_set_len_short(udph, sizeof(amtrh) + sizeof(udph)); udph->check = 0; offset = skb_transport_offset(skb); skb->csum = skb_checksum(skb, offset, skb->len - offset, 0); @@ -2611,7 +2611,7 @@ static void amt_send_advertisement(struct amt_dev amt, __be32 nonce, udph = udp_hdr(skb); udph->source = amt->relay_port; udph->dest = dport; - udph->len = htons(sizeof(amta) + sizeof(udph)); + udp_set_len_short(udph, sizeof(amta) + sizeof(udph)); udph->check = 0; offset = skb_transport_offset(skb); skb->csum = skb_checksum(skb, offset, skb->len - offset, 0); diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c index 894f2d06d39d07..ef5e657816f005 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -3129,7 +3129,7 @@ static int i40e_tso(struct i40e_tx_buffer first, u8 hdr_len, SKB_GSO_UDP_TUNNEL_CSUM)) { if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) && (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) { - l4.udp->len = 0; + udp_set_len_short(l4.udp, 0); / determine offset of outer transport header / l4_offset = l4.hdr - skb->data; diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c index 363c42bf3dcfee..c30abf17cf5d3c 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c @@ -1774,7 +1774,7 @@ static int iavf_tso(struct iavf_tx_buffer first, u8 hdr_len, SKB_GSO_UDP_TUNNEL_CSUM)) { if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) && (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) { - l4.udp->len = 0; + udp_set_len_short(l4.udp, 0); / determine offset of outer transport header / l4_offset = l4.hdr - skb->data; diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c index 4ca1a0602307d0..fdea2758adf155 100644 --- a/drivers/net/ethernet/intel/ice/ice_txrx.c +++ b/drivers/net/ethernet/intel/ice/ice_txrx.c @@ -1893,7 +1893,7 @@ int ice_tso(struct ice_tx_buf first, struct ice_tx_offload_params off) SKB_GSO_UDP_TUNNEL_CSUM)) { if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) && (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) { - l4.udp->len = 0; + udp_set_len_short(l4.udp, 0); / determine offset of outer transport header / l4_start = (u8)(l4.hdr - skb->data); diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index 7f9056404f64fc..566b08ca3a6cb1 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -2871,7 +2871,7 @@ int idpf_tso(struct sk_buff skb, struct idpf_tx_offload_params off) (__force __wsum)htonl(paylen)); / compute length of segmentation header / off->tso_hdr_len = sizeof(struct udphdr) + l4_start; - l4.udp->len = htons(shinfo->gso_size + sizeof(struct udphdr)); + udp_set_len_short(l4.udp, shinfo->gso_size + sizeof(struct udphdr)); break; default: return -EINVAL; diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c index 625bb5a05344c0..8d2d607bc92f9c 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c @@ -750,7 +750,7 @@ static void otx2_sqe_add_ext(struct otx2_nic pfvf, struct otx2_snd_queue sq, ext->lso_format = pfvf->hw.lso_udpv6_idx; } - udph->len = htons(sizeof(struct udphdr)); + udp_set_len_short(udph, sizeof(struct udphdr)); } } else if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) { ext->tstmp = 1; diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c index 6fbc0441c4b845..04af54b704d823 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -1081,7 +1081,7 @@ static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq rq, struct iphdr * struct udphdr uh; uh = (struct udphdr )(skb->data + udp_off); - uh->len = htons(skb->len - udp_off); + udp_set_len_short(uh, skb->len - udp_off); if (uh->check) uh->check = ~udp_v4_check(skb->len - udp_off, ipv4->saddr, @@ -1100,7 +1100,7 @@ static void mlx5e_shampo_update_ipv6_udp_hdr(struct mlx5e_rq rq, struct ipv6hdr struct udphdr uh; uh = (struct udphdr )(skb->data + udp_off); - uh->len = htons(skb->len - udp_off); + udp_set_len_short(uh, skb->len - udp_off); if (uh->check) uh->check = ~udp_v6_check(skb->len - udp_off, &ipv6->saddr, diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c index accc26d1a872db..1dcdb86690bb74 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c @@ -113,7 +113,7 @@ static struct sk_buff mlx5e_test_get_udp_skb(struct mlx5e_priv priv) / Fill UDP header / udph->source = htons(9); udph->dest = htons(9); / Discard Protocol / - udph->len = htons(sizeof(struct mlx5ehdr) + sizeof(struct udphdr)); + udp_set_len_short(udph, sizeof(struct mlx5ehdr) + sizeof(struct udphdr)); udph->check = 0; / Fill IP header / diff --git a/drivers/net/ethernet/sfc/falcon/selftest.c b/drivers/net/ethernet/sfc/falcon/selftest.c index db4dd7fb77f5cb..4d29e0baf2ebe5 100644 --- a/drivers/net/ethernet/sfc/falcon/selftest.c +++ b/drivers/net/ethernet/sfc/falcon/selftest.c @@ -401,8 +401,8 @@ static void ef4_iterate_state(struct ef4_nic efx) /* Initialise udp header / payload->udp.source = 0; - payload->udp.len = htons(sizeof(payload) - - offsetof(struct ef4_loopback_payload, udp)); + udp_set_len_short(&payload->udp, sizeof(payload) - + offsetof(struct ef4_loopback_payload, udp)); payload->udp.check = 0; / checksum ignored / / Fill out payload / diff --git a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c index 8ec76329237a49..dc716feb79cb5a 100644 --- a/drivers/net/ethernet/sfc/selftest.c +++ b/drivers/net/ethernet/sfc/selftest.c @@ -398,8 +398,8 @@ static void efx_iterate_state(struct efx_nic efx) /* Initialise udp header / payload->udp.source = 0; - payload->udp.len = htons(sizeof(payload) - - offsetof(struct efx_loopback_payload, udp)); + udp_set_len_short(&payload->udp, sizeof(payload) - + offsetof(struct efx_loopback_payload, udp)); payload->udp.check = 0; / checksum ignored / / Fill out payload / diff --git a/drivers/net/ethernet/sfc/siena/selftest.c b/drivers/net/ethernet/sfc/siena/selftest.c index 930643612df511..c74cf51313643d 100644 --- a/drivers/net/ethernet/sfc/siena/selftest.c +++ b/drivers/net/ethernet/sfc/siena/selftest.c @@ -399,8 +399,8 @@ static void efx_iterate_state(struct efx_nic efx) /* Initialise udp header / payload->udp.source = 0; - payload->udp.len = htons(sizeof(payload) - - offsetof(struct efx_loopback_payload, udp)); + udp_set_len_short(&payload->udp, sizeof(payload) - + offsetof(struct efx_loopback_payload, udp)); payload->udp.check = 0; / checksum ignored / / Fill out payload / diff --git a/drivers/net/ethernet/sfc/tc_encap_actions.c b/drivers/net/ethernet/sfc/tc_encap_actions.c index db222abef53b2a..c2ad3a358d2012 100644 --- a/drivers/net/ethernet/sfc/tc_encap_actions.c +++ b/drivers/net/ethernet/sfc/tc_encap_actions.c @@ -311,7 +311,7 @@ static void efx_gen_tun_header_udp(struct efx_tc_encap_action encap, u8 len) encap->encap_hdr_len += sizeof(udp); udp->dest = key->tp_dst; - udp->len = cpu_to_be16(sizeof(udp) + len); + udp_set_len_short(udp, sizeof(udp) + len); } static void efx_gen_tun_header_vxlan(struct efx_tc_encap_action encap) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c index a0c75886587c35..29e824bd90ca6b 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c @@ -154,9 +154,9 @@ static struct sk_buff stmmac_test_get_udp_skb(struct stmmac_priv priv, } else { uhdr->source = htons(attr->sport); uhdr->dest = htons(attr->dport); - uhdr->len = htons(sizeof(shdr) + sizeof(uhdr) + attr->size); + udp_set_len_short(uhdr, sizeof(shdr) + sizeof(uhdr) + attr->size); if (attr->max_size) - uhdr->len = htons(attr->max_size - + udp_set_len_short(uhdr, attr->max_size - (sizeof(ihdr) + sizeof(ehdr))); uhdr->check = 0; } diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index 396e1a113cd49e..a1639ad53077ec 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c @@ -631,7 +631,7 @@ static int geneve_post_decap_hint(const struct sock sk, struct sk_buff skb, /* Adjust the nested UDP header len and checksum. / uh = udp_hdr(skb); - uh->len = htons(skb->len - gro_hint->nested_tp_offset); + udp_set_len_short(uh, skb->len - gro_hint->nested_tp_offset); if (uh->check) { len = skb->len - gro_hint->nested_tp_offset; skb_shinfo(skb)->gso_type \|= SKB_GSO_UDP_TUNNEL_CSUM; @@ -1745,6 +1745,8 @@ static void geneve_setup(struct net_device dev) dev->max_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev->hard_header_len; netif_keep_dst(dev); + netif_set_tso_max_size(dev, GSO_MAX_SIZE); + dev->priv_flags &= ~IFF_TX_SKB_SHARING; dev->priv_flags \|= IFF_LIVE_ADDR_CHANGE \| IFF_NO_QUEUE; dev->lltx = true; diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c index c1812a98365b78..a531548eb89138 100644 --- a/drivers/net/netconsole.c +++ b/drivers/net/netconsole.c @@ -1792,7 +1792,7 @@ static void push_udp(struct netpoll np, struct sk_buff skb, int len) udph = udp_hdr(skb); udph->source = htons(np->local_port); udph->dest = htons(np->remote_port); - udph->len = htons(udp_len); + udp_set_len_short(udph, udp_len); netpoll_udp_checksum(np, skb, len); } diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c index aed9ad5f1b43af..f65b4cf4ea392b 100644 --- a/drivers/net/netdevsim/dev.c +++ b/drivers/net/netdevsim/dev.c @@ -845,7 +845,7 @@ static struct sk_buff nsim_dev_trap_skb_build(void) udph = skb_put_zero(skb, sizeof(struct udphdr) + data_len); get_random_bytes(&udph->source, sizeof(u16)); get_random_bytes(&udph->dest, sizeof(u16)); - udph->len = htons(sizeof(struct udphdr) + data_len); + udp_set_len_short(udph, sizeof(struct udphdr) + data_len); return skb; } diff --git a/drivers/net/netdevsim/psample.c b/drivers/net/netdevsim/psample.c index 717d157c3ae2b6..1e71c3da4def52 100644 --- a/drivers/net/netdevsim/psample.c +++ b/drivers/net/netdevsim/psample.c @@ -73,7 +73,7 @@ static struct sk_buff nsim_dev_psample_skb_build(void) udph = skb_put_zero(skb, sizeof(struct udphdr) + data_len); get_random_bytes(&udph->source, sizeof(u16)); get_random_bytes(&udph->dest, sizeof(u16)); - udph->len = htons(sizeof(struct udphdr) + data_len); + udp_set_len_short(udph, sizeof(struct udphdr) + data_len); return skb; } diff --git a/drivers/net/netdevsim/psp.c b/drivers/net/netdevsim/psp.c index 59c990fdc79ecd..6b3532b5e360d5 100644 --- a/drivers/net/netdevsim/psp.c +++ b/drivers/net/netdevsim/psp.c @@ -84,6 +84,7 @@ nsim_do_psp(struct sk_buff skb, struct netdevsim ns, struct iphdr iph; struct udphdr uh; __wsum csum; + int udplen; /* Do not decapsulate. Receive the skb with the udp and psp * headers still there as if this is a normal udp packet. @@ -91,19 +92,20 @@ nsim_do_psp(struct sk_buff skb, struct netdevsim ns, * provide a valid checksum here, so the skb isn't dropped. / uh = udp_hdr(skb); + udplen = udp_get_len(skb, uh, skb_transport_offset(skb)); csum = skb_checksum(skb, skb_transport_offset(skb), - ntohs(uh->len), 0); + udplen, 0); switch (skb->protocol) { case htons(ETH_P_IP): iph = ip_hdr(skb); - uh->check = udp_v4_check(ntohs(uh->len), iph->saddr, + uh->check = udp_v4_check(udplen, iph->saddr, iph->daddr, csum); break; #if IS_ENABLED(CONFIG_IPV6) case htons(ETH_P_IPV6): ip6h = ipv6_hdr(skb); - uh->check = udp_v6_check(ntohs(uh->len), &ip6h->saddr, + uh->check = udp_v6_check(udplen, &ip6h->saddr, &ip6h->daddr, csum); break; #endif diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c index 67c367cc566233..3a32f067e701df 100644 --- a/drivers/net/vxlan/vxlan_core.c +++ b/drivers/net/vxlan/vxlan_core.c @@ -3370,6 +3370,8 @@ static void vxlan_setup(struct net_device dev) dev->mangleid_features = NETIF_F_GSO_PARTIAL; netif_keep_dst(dev); + netif_set_tso_max_size(dev, GSO_MAX_SIZE); + dev->priv_flags \|= IFF_NO_QUEUE; dev->change_proto_down = true; dev->lltx = true; diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c index eb8851113654f5..824bbefce61c78 100644 --- a/drivers/net/wireguard/receive.c +++ b/drivers/net/wireguard/receive.c @@ -62,7 +62,7 @@ static int prepare_skb_header(struct sk_buff skb, struct wg_device wg) * to have UDP fields. / return -EINVAL; - data_len = ntohs(udp->len); + data_len = udp_get_len_short(udp); if (unlikely(data_len < sizeof(struct udphdr) \|\| data_len > skb->len - data_offset)) / UDP packet is reporting too small of a size or lying about diff --git a/include/linux/udp.h b/include/linux/udp.h index ce56ebcee5cbcd..998906ec3b32ad 100644 --- a/include/linux/udp.h +++ b/include/linux/udp.h @@ -23,6 +23,33 @@ static inline struct udphdr udp_hdr(const struct sk_buff skb) return (struct udphdr )skb_transport_header(skb); } +static inline unsigned int udp_get_len(const struct sk_buff skb, + const struct udphdr uh, + unsigned int dataoff) +{ + if (uh->len) + return ntohs(uh->len); + if (skb_is_gso(skb)) / BIG TCP / + return skb->len - dataoff; + return 0; +} + +static inline unsigned int udp_get_len_short(const struct udphdr uh) +{ + return ntohs(uh->len); +} + +static inline void udp_set_len(struct udphdr uh, unsigned int len) +{ + uh->len = len < GRO_LEGACY_MAX_SIZE ? htons(len) : 0; +} + +static inline void udp_set_len_short(struct udphdr uh, unsigned int len) +{ + DEBUG_NET_WARN_ON_ONCE(len >= GRO_LEGACY_MAX_SIZE); + uh->len = htons(len); +} + #define UDP_HTABLE_SIZE_MIN_PERNET 128 #define UDP_HTABLE_SIZE_MIN (IS_ENABLED(CONFIG_BASE_SMALL) ? 128 : 256) #define UDP_HTABLE_SIZE_MAX 65536 diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h index 31559796949a78..09ae115099dfe2 100644 --- a/include/trace/events/icmp.h +++ b/include/trace/events/icmp.h @@ -44,7 +44,7 @@ TRACE_EVENT(icmp_send, } else { __entry->sport = ntohs(uh->source); __entry->dport = ntohs(uh->dest); - __entry->ulen = ntohs(uh->len); + __entry->ulen = udp_get_len_short(uh); } p32 = (__be32 ) __entry->saddr; diff --git a/lib/tests/blackhole_dev_kunit.c b/lib/tests/blackhole_dev_kunit.c index 06834ab35f43c5..fa3e0533038d6f 100644 --- a/lib/tests/blackhole_dev_kunit.c +++ b/lib/tests/blackhole_dev_kunit.c @@ -46,7 +46,7 @@ static void test_blackholedev(struct kunit test) uh = (struct udphdr )skb_push(skb, sizeof(struct udphdr)); skb_set_transport_header(skb, 0); uh->source = uh->dest = htons(UDP_PORT); - uh->len = htons(data_len); + udp_set_len_short(uh, data_len); uh->check = 0; / (Network) IPv6 / ip6h = (struct ipv6hdr )skb_push(skb, sizeof(struct ipv6hdr)); diff --git a/net/6lowpan/nhc_udp.c b/net/6lowpan/nhc_udp.c index 0a506c77283dde..ed4227e6db7442 100644 --- a/net/6lowpan/nhc_udp.c +++ b/net/6lowpan/nhc_udp.c @@ -88,16 +88,16 @@ static int udp_uncompress(struct sk_buff skb, size_t needed) switch (lowpan_dev(skb->dev)->lltype) { case LOWPAN_LLTYPE_IEEE802154: if (lowpan_802154_cb(skb)->d_size) - uh.len = htons(lowpan_802154_cb(skb)->d_size - - sizeof(struct ipv6hdr)); + udp_set_len_short(&uh, lowpan_802154_cb(skb)->d_size - + sizeof(struct ipv6hdr)); else - uh.len = htons(skb->len + sizeof(struct udphdr)); + udp_set_len_short(&uh, skb->len + sizeof(struct udphdr)); break; default: - uh.len = htons(skb->len + sizeof(struct udphdr)); + udp_set_len_short(&uh, skb->len + sizeof(struct udphdr)); break; } - pr_debug("uncompressed UDP length: src = %d", ntohs(uh.len)); + pr_debug("uncompressed UDP length: src = %d", udp_get_len_short(&uh)); / replace the compressed UDP head by the uncompressed UDP * header diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 8e185b31828853..5b4dd04d612476 100644 --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -3005,7 +3005,7 @@ static struct sk_buff fill_packet_ipv4(struct net_device odev, udph->source = htons(pkt_dev->cur_udp_src); udph->dest = htons(pkt_dev->cur_udp_dst); - udph->len = htons(datalen + 8); /* DATA + udphdr / + udp_set_len_short(udph, datalen + 8); / DATA + udphdr / udph->check = 0; iph->ihl = 5; @@ -3138,7 +3138,7 @@ static struct sk_buff fill_packet_ipv6(struct net_device odev, udplen = datalen + sizeof(struct udphdr); udph->source = htons(pkt_dev->cur_udp_src); udph->dest = htons(pkt_dev->cur_udp_dst); - udph->len = htons(udplen); + udp_set_len_short(udph, udplen); udph->check = 0; (__be32 ) iph = htonl(0x60000000); / Version + flow / diff --git a/net/core/selftests.c b/net/core/selftests.c index 0a203d3fb9dcbe..36b949ae520b31 100644 --- a/net/core/selftests.c +++ b/net/core/selftests.c @@ -72,9 +72,9 @@ struct sk_buff net_test_get_skb(struct net_device ndev, u8 id, } else { uhdr->source = htons(attr->sport); uhdr->dest = htons(attr->dport); - uhdr->len = htons(sizeof(shdr) + sizeof(uhdr) + attr->size); + udp_set_len_short(uhdr, sizeof(shdr) + sizeof(uhdr) + attr->size); if (attr->max_size) - uhdr->len = htons(attr->max_size - + udp_set_len_short(uhdr, attr->max_size - (sizeof(ihdr) + sizeof(ehdr))); uhdr->check = 0; } diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 18dabb4e9cfa0e..6ae4c2b205f2ef 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4775,6 +4775,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb, struct sk_buff tail = NULL; struct sk_buff list_skb = skb_shinfo(head_skb)->frag_list; unsigned int mss = skb_shinfo(head_skb)->gso_size; + bool gso_by_frags = mss == GSO_BY_FRAGS; unsigned int doffset = head_skb->data - skb_mac_header(head_skb); unsigned int offset = doffset; unsigned int tnl_hlen = skb_tnl_header_len(head_skb); @@ -4790,7 +4791,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb, int nfrags, pos; if ((skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY) && - mss != GSO_BY_FRAGS && mss != skb_headlen(head_skb)) { + !gso_by_frags && mss != skb_headlen(head_skb)) { struct sk_buff check_skb; for (check_skb = list_skb; check_skb; check_skb = check_skb->next) { @@ -4818,7 +4819,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb, sg = !!(features & NETIF_F_SG); csum = !!can_checksum_protocol(features, proto); - if (sg && csum && (mss != GSO_BY_FRAGS)) { + if (sg && csum && !gso_by_frags) { if (!(features & NETIF_F_GSO_PARTIAL)) { struct sk_buff iter; unsigned int frag_len; @@ -4852,9 +4853,8 @@ struct sk_buff skb_segment(struct sk_buff head_skb, / GSO partial only requires that we trim off any excess that * doesn't fit into an MSS sized block, so take care of that * now. - * Cap len to not accidentally hit GSO_BY_FRAGS. / - partial_segs = min(len, GSO_BY_FRAGS - 1) / mss; + partial_segs = len / mss; if (partial_segs > 1) mss = partial_segs; else @@ -4878,7 +4878,7 @@ struct sk_buff skb_segment(struct sk_buff head_skb, int hsize; int size; - if (unlikely(mss == GSO_BY_FRAGS)) { + if (unlikely(gso_by_frags)) { len = list_skb->len; } else { len = head_skb->len - offset; diff --git a/net/core/tso.c b/net/core/tso.c index 347b3856ddb91f..d2934bcfa795f0 100644 --- a/net/core/tso.c +++ b/net/core/tso.c @@ -39,7 +39,8 @@ void tso_build_hdr(const struct sk_buff skb, char hdr, struct tso_t tso, } else { struct udphdr uh = (struct udphdr )hdr; - uh->len = htons(sizeof(uh) + size); + /* size is after segmentation. / + udp_set_len_short(uh, sizeof(uh) + size); } } EXPORT_SYMBOL(tso_build_hdr); diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c index dfc81ee969ae03..a6c18aea7498d8 100644 --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -323,7 +323,7 @@ static struct ip_esp_hdr esp_output_udp_encap(struct sk_buff skb, uh = (struct udphdr )esp->esph; uh->source = sport; uh->dest = dport; - uh->len = htons(len); + udp_set_len_short(uh, len); uh->check = 0; / For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload diff --git a/net/ipv4/fou_core.c b/net/ipv4/fou_core.c index 865bd7205122d2..aef3ce1dec7aa2 100644 --- a/net/ipv4/fou_core.c +++ b/net/ipv4/fou_core.c @@ -1040,7 +1040,7 @@ static void fou_build_udp(struct sk_buff skb, struct ip_tunnel_encap e, uh->dest = e->dport; uh->source = sport; - uh->len = htons(skb->len); + udp_set_len(uh, skb->len); udp_set_csum(!(e->flags & TUNNEL_ENCAP_FLAG_CSUM), skb, fl4->saddr, fl4->daddr, skb->len); diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c index a35ffedacc7c7f..155db067eaecbe 100644 --- a/net/ipv4/ipconfig.c +++ b/net/ipv4/ipconfig.c @@ -847,7 +847,7 @@ static void __init ic_bootp_send_if(struct ic_device d, unsigned long jiffies_d / Construct UDP header / b->udph.source = htons(68); b->udph.dest = htons(67); - b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr)); + udp_set_len_short(&b->udph, sizeof(struct bootp_pkt) - sizeof(struct iphdr)); / UDP checksum not calculated -- explicitly allowed in BOOTP RFC / / Construct DHCP/BOOTP header / @@ -1025,10 +1025,10 @@ static int __init ic_bootp_recv(struct sk_buff skb, struct net_device dev, str if (b->udph.source != htons(67) \|\| b->udph.dest != htons(68)) goto drop; - if (ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr)) + if (ntohs(h->tot_len) < udp_get_len_short(&b->udph) + sizeof(struct iphdr)) goto drop; - len = ntohs(b->udph.len) - sizeof(struct udphdr); + len = udp_get_len_short(&b->udph) - sizeof(struct udphdr); ext_len = len - (sizeof(b) - sizeof(struct iphdr) - sizeof(struct udphdr) - diff --git a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c index e540b86bd15b6b..4492bc548a66bf 100644 --- a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c +++ b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c @@ -127,7 +127,7 @@ static int snmp_translate(struct nf_conn ct, int dir, struct sk_buff skb) { struct iphdr iph = ip_hdr(skb); struct udphdr udph = (struct udphdr )((__be32 )iph + iph->ihl); - u16 datalen = ntohs(udph->len) - sizeof(struct udphdr); + u16 datalen = udp_get_len_short(udph) - sizeof(struct udphdr); char data = (unsigned char )udph + sizeof(struct udphdr); struct snmp_ctx ctx; int ret; @@ -181,7 +181,7 @@ static int help(struct sk_buff skb, unsigned int protoff, enough room for a UDP header. Just verify the UDP length field so we * can mess around with the payload. / - if (ntohs(udph->len) != skb->len - (iph->ihl << 2)) { + if (udp_get_len_short(udph) != skb->len - (iph->ihl << 2)) { nf_ct_helper_log(skb, ct, "dropping malformed packet\n"); return NF_DROP; } diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 3f3de5164d6e58..0825ed9837146c 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -3187,7 +3187,7 @@ static struct sk_buff inet_rtm_getroute_build_skb(__be32 src, __be32 dst, udph = skb_put_zero(skb, sizeof(struct udphdr)); udph->source = sport; udph->dest = dport; - udph->len = htons(sizeof(struct udphdr)); + udp_set_len_short(udph, sizeof(struct udphdr)); udph->check = 0; break; } diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index 59248a59358ca5..2b9b55a147582b 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1108,7 +1108,8 @@ static int udp_send_skb(struct sk_buff skb, struct flowi4 fl4, uh = udp_hdr(skb); uh->source = inet_sk(sk)->inet_sport; uh->dest = fl4->fl4_dport; - uh->len = htons(len); + /* Datagram length checked in udp_sendmsg. / + udp_set_len_short(uh, len); uh->check = 0; if (cork->gso_size) { @@ -2591,8 +2592,8 @@ int udp_rcv(struct sk_buff skb) struct rtable rt = skb_rtable(skb); struct net net = dev_net(skb->dev); struct sock sk = NULL; - unsigned short ulen; __be32 saddr, daddr; + unsigned int ulen; struct udphdr uh; bool refcounted; int drop_reason; @@ -2606,7 +2607,7 @@ int udp_rcv(struct sk_buff skb) goto drop; / No space for header. / uh = udp_hdr(skb); - ulen = ntohs(uh->len); + ulen = udp_get_len(skb, uh, 0); saddr = ip_hdr(skb)->saddr; daddr = ip_hdr(skb)->daddr; diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index 29651b1a0bc704..8f77c8788f6db0 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -279,11 +279,11 @@ static struct sk_buff __skb_udp_tunnel_segment(struct sk_buff skb, segment instead of the entire frame. / if (gso_partial && skb_is_gso(skb)) { - uh->len = htons(skb_shinfo(skb)->gso_size + - SKB_GSO_CB(skb)->data_offset + - skb->head - (unsigned char )uh); + udp_set_len_short(uh, skb_shinfo(skb)->gso_size + + SKB_GSO_CB(skb)->data_offset + + skb->head - (unsigned char )uh); } else { - uh->len = htons(len); + udp_set_len_short(uh, len); } if (!need_csum) @@ -468,7 +468,7 @@ static struct sk_buff __udp_gso_segment_list(struct sk_buff skb, if (IS_ERR(skb)) return skb; - udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss); + udp_set_len_short(udp_hdr(skb), sizeof(struct udphdr) + mss); if (is_ipv6) return __udpv6_gso_segment_list_csum(skb); @@ -486,8 +486,8 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb, unsigned int mss; bool copy_dtor; __sum16 check; - __be16 newlen; int ret = 0; + u16 newlen; mss = skb_shinfo(gso_skb)->gso_size; if (gso_skb->len <= sizeof(uh) + mss) @@ -564,8 +564,8 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb, (skb_shinfo(gso_skb)->tx_flags & SKBTX_ANY_TSTAMP); /* compute checksum adjustment based on old length versus new / - newlen = htons(sizeof(uh) + mss); - check = csum16_add(csum16_sub(uh->check, uh->len), newlen); + newlen = sizeof(uh) + mss; + check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen)); for (;;) { if (copy_dtor) { @@ -577,7 +577,7 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb, if (!seg->next) break; - uh->len = newlen; + udp_set_len_short(uh, newlen); uh->check = check; if (seg->ip_summed == CHECKSUM_PARTIAL) @@ -594,11 +594,10 @@ struct sk_buff __udp_gso_segment(struct sk_buff gso_skb, segment may not be full MSS, account for that in the checksum / if (!skb_is_gso(seg)) - newlen = htons(skb_tail_pointer(seg) - - skb_transport_header(seg) + seg->data_len); - check = csum16_add(csum16_sub(uh->check, uh->len), newlen); + newlen = skb_tail_pointer(seg) - skb_transport_header(seg) + seg->data_len; + check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen)); - uh->len = newlen; + udp_set_len_short(uh, newlen); uh->check = check; if (seg->ip_summed == CHECKSUM_PARTIAL) @@ -708,12 +707,8 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head, return NULL; } - / Do not deal with padded or malicious packets, sorry ! / - ulen = ntohs(uh->len); - if (ulen <= sizeof(uh) \|\| ulen != skb_gro_len(skb)) { - NAPI_GRO_CB(skb)->flush = 1; - return NULL; - } + ulen = udp_get_len_short(uh); + /* pull encapsulating udp header / skb_gro_pull(skb, sizeof(struct udphdr)); @@ -742,7 +737,7 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head, On len mismatch merge the first packet shorter than gso_size, * otherwise complete the GRO packet. / - if (ulen > ntohs(uh2->len) \|\| flush) { + if (ulen > udp_get_len_short(uh2) \|\| flush) { pp = p; } else { if (NAPI_GRO_CB(skb)->is_flist) { @@ -765,7 +760,7 @@ static struct sk_buff udp_gro_receive_segment(struct list_head head, } } - if (ret \|\| ulen != ntohs(uh2->len) \|\| + if (ret \|\| ulen != udp_get_len_short(uh2) \|\| NAPI_GRO_CB(p)->count >= UDP_GRO_CNT_MAX) pp = p; @@ -783,8 +778,14 @@ struct sk_buff udp_gro_receive(struct list_head head, struct sk_buff skb, struct sk_buff p; struct udphdr uh2; unsigned int off = skb_gro_offset(skb); + unsigned int ulen; int flush = 1; + /* Do not deal with padded or malicious packets, sorry! / + ulen = udp_get_len_short(uh); + if (ulen <= sizeof(uh) \|\| ulen != skb_gro_len(skb)) + goto out; + /* We can do L4 aggregation only if the packet can't land in a tunnel * otherwise we could corrupt the inner stream. Detecting such packets * cannot be foolproof and the aggregation might still happen in some @@ -915,12 +916,12 @@ static int udp_gro_complete_segment(struct sk_buff skb) int udp_gro_complete(struct sk_buff skb, int nhoff, udp_lookup_t lookup) { - __be16 newlen = htons(skb->len - nhoff); struct udphdr uh = (struct udphdr )(skb->data + nhoff); + unsigned int newlen = skb->len - nhoff; struct sock sk; int err; - uh->len = newlen; + udp_set_len(uh, newlen); sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb, udp4_lib_lookup_skb, skb, uh->source, uh->dest); @@ -957,7 +958,7 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff skb, int nhoff) /* do fraglist only if there is no outer UDP encap (or we already processed it) / if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) { - uh->len = htons(skb->len - nhoff); + udp_set_len(uh, skb->len - nhoff); skb_shinfo(skb)->gso_type \|= (SKB_GSO_FRAGLIST\|SKB_GSO_UDP_L4); skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count; diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c index 9ab3728f9630bf..a128fe85620d30 100644 --- a/net/ipv4/udp_tunnel_core.c +++ b/net/ipv4/udp_tunnel_core.c @@ -178,7 +178,7 @@ void udp_tunnel_xmit_skb(struct rtable rt, struct sock sk, struct sk_buff skb uh->dest = dst_port; uh->source = src_port; - uh->len = htons(skb->len); + udp_set_len(uh, skb->len); memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index 296b57926abb98..72ec0d7d112090 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -230,7 +230,8 @@ static void esp_output_encap_csum(struct sk_buff skb) if (skb_mac_header(skb) == IPPROTO_UDP) { struct udphdr uh = udp_hdr(skb); struct ipv6hdr ip6h = ipv6_hdr(skb); - int len = ntohs(uh->len); + /* esp6_output_udp_encap limits len to U16_MAX. / + int len = udp_get_len_short(uh); unsigned int offset = skb_transport_offset(skb); __wsum csum = skb_checksum(skb, offset, skb->len - offset, 0); @@ -358,7 +359,7 @@ static struct ip_esp_hdr esp6_output_udp_encap(struct sk_buff skb, uh = (struct udphdr )esp->esph; uh->source = sport; uh->dest = dport; - uh->len = htons(len); + udp_set_len_short(uh, len); uh->check = 0; skb_mac_header(skb) = IPPROTO_UDP; diff --git a/net/ipv6/fou6.c b/net/ipv6/fou6.c index 157765259e2f5f..4b659ca60ba9a8 100644 --- a/net/ipv6/fou6.c +++ b/net/ipv6/fou6.c @@ -30,7 +30,7 @@ static void fou6_build_udp(struct sk_buff skb, struct ip_tunnel_encap e, uh->dest = e->dport; uh->source = sport; - uh->len = htons(skb->len); + udp_set_len(uh, skb->len); udp6_set_csum(!(e->flags & TUNNEL_ENCAP_FLAG_CSUM6), skb, &fl6->saddr, &fl6->daddr, skb->len); diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c index 9adb5775487fac..32525a051a6f08 100644 --- a/net/ipv6/ip6_udp_tunnel.c +++ b/net/ipv6/ip6_udp_tunnel.c @@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry dst, struct sock sk, uh->dest = dst_port; uh->source = src_port; - uh->len = htons(skb->len); + udp_set_len(uh, skb->len); skb_dst_set(skb, dst); diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index 392e18b9704544..02272466f4c298 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -1081,12 +1081,12 @@ INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff skb) daddr = &ipv6_hdr(skb)->daddr; uh = udp_hdr(skb); - ulen = ntohs(uh->len); + ulen = udp_get_len(skb, uh, 0); if (ulen > skb->len) goto short_packet; /* Check for jumbo payload / - if (ulen == 0) + if (ulen == 0 && inet6_is_jumbogram(skb)) ulen = skb->len; if (ulen < sizeof(uh)) @@ -1369,7 +1369,8 @@ static int udp_v6_send_skb(struct sk_buff skb, struct flowi6 fl6, uh = udp_hdr(skb); uh->source = fl6->fl6_sport; uh->dest = fl6->fl6_dport; - uh->len = htons(len); + /* Datagram length checked in udpv6_sendmsg. / + udp_set_len_short(uh, len); uh->check = 0; if (cork->gso_size) { diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c index 778afc7453ce53..7370bcb80332ea 100644 --- a/net/ipv6/udp_offload.c +++ b/net/ipv6/udp_offload.c @@ -171,7 +171,7 @@ int udp6_gro_complete(struct sk_buff skb, int nhoff) /* do fraglist only if there is no outer UDP encap (or we already processed it) / if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) { - uh->len = htons(skb->len - nhoff); + udp_set_len(uh, skb->len - nhoff); skb_shinfo(skb)->gso_type \|= (SKB_GSO_FRAGLIST\|SKB_GSO_UDP_L4); skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count; diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index f940914959b18e..4712cc41881a30 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1296,7 +1296,7 @@ static int l2tp_xmit_core(struct l2tp_session session, struct sk_buff skb, uns ret = NET_XMIT_DROP; goto out_unlock; } - uh->len = htons(udp_len); + udp_set_len_short(uh, udp_len); / Calculate UDP checksum if configured to do so / #if IS_ENABLED(CONFIG_IPV6) diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c index ce542ed4b013c8..c51ebd83a476fe 100644 --- a/net/netfilter/ipvs/ip_vs_xmit.c +++ b/net/netfilter/ipvs/ip_vs_xmit.c @@ -1100,7 +1100,7 @@ ipvs_gue_encap(struct net net, struct sk_buff skb, dport = cp->dest->tun_port; udph->dest = dport; udph->source = sport; - udph->len = htons(skb->len); + udp_set_len(udph, skb->len); udph->check = 0; next_protocol = IPPROTO_UDP; diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c index cc9b7e5e19358d..a7edfefd6fd14b 100644 --- a/net/netfilter/nf_conntrack_proto_udp.c +++ b/net/netfilter/nf_conntrack_proto_udp.c @@ -41,11 +41,22 @@ static void udp_error_log(const struct sk_buff skb, nf_l4proto_log_invalid(skb, state, IPPROTO_UDP, "%s", msg); } +static bool udp_validate_len(struct sk_buff skb, + const struct udphdr hdr, + unsigned int dataoff) +{ + unsigned int udplen = udp_get_len(skb, hdr, dataoff); + unsigned int skblen = skb->len - dataoff; + + if (udplen > skblen \|\| udplen < sizeof(hdr)) + return false; + return true; +} + static bool udp_error(struct sk_buff skb, unsigned int dataoff, const struct nf_hook_state state) { - unsigned int udplen = skb->len - dataoff; const struct udphdr hdr; struct udphdr _hdr; @@ -57,7 +68,7 @@ static bool udp_error(struct sk_buff skb, } /* Truncated/malformed packets / - if (ntohs(hdr->len) > udplen \|\| ntohs(hdr->len) < sizeof(hdr)) { + if (!udp_validate_len(skb, hdr, dataoff)) { udp_error_log(skb, state, "truncated/malformed packet"); return true; } diff --git a/net/netfilter/nf_log_syslog.c b/net/netfilter/nf_log_syslog.c index e37b09b3203b75..71dff0eb672c43 100644 --- a/net/netfilter/nf_log_syslog.c +++ b/net/netfilter/nf_log_syslog.c @@ -301,7 +301,7 @@ nf_log_dump_udp_header(struct nf_log_buf m, / Max length: 20 "SPT=65535 DPT=65535 " / nf_log_buf_add(m, "SPT=%u DPT=%u LEN=%u ", - ntohs(uh->source), ntohs(uh->dest), ntohs(uh->len)); + ntohs(uh->source), ntohs(uh->dest), udp_get_len_short(uh)); out: return 0; diff --git a/net/netfilter/nf_nat_helper.c b/net/netfilter/nf_nat_helper.c index bf591e6af0051a..3853f41db49953 100644 --- a/net/netfilter/nf_nat_helper.c +++ b/net/netfilter/nf_nat_helper.c @@ -161,7 +161,7 @@ nf_nat_mangle_udp_packet(struct sk_buff skb, /* update the length of the UDP packet / datalen = skb->len - protoff; - udph->len = htons(datalen); + udp_set_len_short(udph, datalen); / fix udp checksum if udp checksum was previously calculated / if (!udph->check && skb->ip_summed != CHECKSUM_PARTIAL) diff --git a/net/psp/psp_main.c b/net/psp/psp_main.c index 8b2f178e317cb8..c9c1a8826b7f92 100644 --- a/net/psp/psp_main.c +++ b/net/psp/psp_main.c @@ -231,7 +231,7 @@ static void psp_write_headers(struct net net, struct sk_buff skb, __be32 spi, uh->source = udp_flow_src_port(net, skb, 0, 0, false); } uh->check = 0; - uh->len = htons(udp_len); + udp_set_len(uh, udp_len); psph->nexthdr = IPPROTO_TCP; psph->hdrlen = PSP_HDRLEN_NOOPT; diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c index 078d3a27130b8d..5fff52a8ca90dc 100644 --- a/net/sched/act_csum.c +++ b/net/sched/act_csum.c @@ -276,7 +276,7 @@ static int tcf_csum_ipv4_udp(struct sk_buff skb, unsigned int ihl, return 0; iph = ip_hdr(skb); - ul = ntohs(udph->len); + ul = udp_get_len_short(udph); if (udplite \|\| udph->check) { @@ -334,7 +334,7 @@ static int tcf_csum_ipv6_udp(struct sk_buff skb, unsigned int ihl, return 0; ip6h = ipv6_hdr(skb); - ul = ntohs(udph->len); + ul = udp_get_len_short(udph); udph->check = 0; diff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c index 458931062a04ef..906458f3d8c525 100644 --- a/net/xfrm/xfrm_nat_keepalive.c +++ b/net/xfrm/xfrm_nat_keepalive.c @@ -133,7 +133,7 @@ static void nat_keepalive_send(struct nat_keepalive ka) uh = skb_push(skb, sizeof(*uh)); uh->source = ka->encap_sport; uh->dest = ka->encap_dport; - uh->len = htons(skb->len); + udp_set_len_short(uh, skb->len); uh->check = 0; skb->mark = ka->smark; diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile index 708d960ae07d5b..4cb0a0bc1eeace 100644 --- a/tools/testing/selftests/net/Makefile +++ b/tools/testing/selftests/net/Makefile @@ -13,6 +13,7 @@ TEST_PROGS := \ arp_ndisc_untracked_subnets.sh \ bareudp.sh \ big_tcp.sh \ + big_tcp_tunnels.sh \ bind_bhash.sh \ bpf_offload.py \ bridge_stp_mode.sh \ diff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh new file mode 100755 index 00000000000000..128a710e74ad5a --- /dev/null +++ b/tools/testing/selftests/net/big_tcp_tunnels.sh @@ -0,0 +1,183 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: GPL-2.0 +# +# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels. + +SERVER_NS=$(mktemp -u server-XXXXXXXX) +SERVER_IP4="192.168.1.1" +SERVER_IP6="2001:db8::1:1" +SERVER_IP4_TUN="192.168.2.1" +SERVER_IP6_TUN="2001:db8::2:1" + +CLIENT_NS=$(mktemp -u client-XXXXXXXX) +CLIENT_IP4="192.168.1.2" +CLIENT_IP6="2001:db8::1:2" +CLIENT_IP4_TUN="192.168.2.2" +CLIENT_IP6_TUN="2001:db8::2:2" + +: "${PACKETS_THRESHOLD:=1000}" + +# Kselftest framework requirement - SKIP code is 4. +ksft_skip=4 + +setup() { + ip netns add "$SERVER_NS" + ip netns add "$CLIENT_NS" + ip -netns "$SERVER_NS" link add link1 type veth peer name link0 netns "$CLIENT_NS" + + ip -netns "$CLIENT_NS" link set link0 up + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4/24" dev link0 + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6/112" dev link0 nodad + ip -netns "$CLIENT_NS" link set link0 \ + gso_max_size 196608 gso_ipv4_max_size 196608 \ + gro_max_size 196608 gro_ipv4_max_size 196608 + ip -netns "$SERVER_NS" link set link1 up + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4/24" dev link1 + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6/112" dev link1 nodad + ip -netns "$SERVER_NS" link set link1 \ + gso_max_size 196608 gso_ipv4_max_size 196608 \ + gro_max_size 196608 gro_ipv4_max_size 196608 + + ip netns exec "$SERVER_NS" netserver >/dev/null +} + +setup_tunnel() { + if [ "$2" = 4 ]; then + SERVER_IP="$SERVER_IP4" + CLIENT_IP="$CLIENT_IP4" + echo "Setting up ${1^^} over IPv4, veth tx csum offload $3" + else + SERVER_IP="$SERVER_IP6" + CLIENT_IP="$CLIENT_IP6" + echo "Setting up ${1^^} over IPv6, veth tx csum offload $3" + fi + + if [ "$1" = vxlan ]; then + ip -netns "$CLIENT_NS" link add tun0 type vxlan \ + id 5001 remote "$SERVER_IP" local "$CLIENT_IP" dev link0 dstport 4789 + else + ip -netns "$CLIENT_NS" link add tun0 type geneve \ + id 5001 remote "$SERVER_IP" + fi + ip -netns "$CLIENT_NS" link set tun0 up + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4_TUN/24" dev tun0 + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6_TUN/112" dev tun0 nodad + ip -netns "$CLIENT_NS" link set tun0 \ + gso_max_size 196608 gso_ipv4_max_size 196608 \ + gro_max_size 196608 gro_ipv4_max_size 196608 + if [ "$1" = vxlan ]; then + ip -netns "$SERVER_NS" link add tun1 type vxlan \ + id 5001 remote "$CLIENT_IP" local "$SERVER_IP" dev link1 dstport 4789 + else + ip -netns "$SERVER_NS" link add tun1 type geneve \ + id 5001 remote "$CLIENT_IP" + fi + ip -netns "$SERVER_NS" link set tun1 up + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4_TUN/24" dev tun1 + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6_TUN/112" dev tun1 nodad + ip -netns "$SERVER_NS" link set tun1 \ + gso_max_size 196608 gso_ipv4_max_size 196608 \ + gro_max_size 196608 gro_ipv4_max_size 196608 + + ip netns exec "$CLIENT_NS" ethtool -K link0 tx-checksumming "$3" > /dev/null + ip netns exec "$SERVER_NS" ethtool -K link1 tx-checksumming "$3" > /dev/null +} + +cleanup_tunnel() { + ip -netns "$CLIENT_NS" link del tun0 + ip -netns "$SERVER_NS" link del tun1 +} + +cleanup() { + ip netns pids "$SERVER_NS" \| xargs -r kill + ip netns pids "$CLIENT_NS" \| xargs -r kill + ip netns del "$SERVER_NS" + ip netns del "$CLIENT_NS" + rm -rf "$WORKDIR" +} + +do_test() { + # When tx csum offload is off, software GSO is performed before passing the + # packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify + # the software checksum path: if the checksum code is broken, these packets + # will be dropped. + if [ "$2" = on ]; then + CAPTURE_IFACE='link' + else + CAPTURE_IFACE='tun' + fi + + ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}1" greater 65536 -w "$WORKDIR/server.pcap" 2> /dev/null & + TCPDUMP_SERVER_PID="$!" + ip netns exec "$CLIENT_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}0" greater 65536 -w "$WORKDIR/client.pcap" 2> /dev/null & + TCPDUMP_CLIENT_PID="$!" + + # This filter doesn't capture all possible variants of SACK, but it's aimed + # at the typical one where SACK follows after [nop, nop, timestamp, nop, + # nop] (14 bytes after the 20-byte TCP header). IPv6 needs a separate match, + # because man tcpdump says: + # > Arithmetic expression against transport layer headers, like tcp[0], does + # > not work against IPv6 packets. It only looks at IPv4 packets. + ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "tun1" '(tcp[tcpflags] & (tcp-syn\|tcp-ack) = tcp-ack and tcp[34:2] & 0xffc3 = 0x0502) or (ip6[6] = 0x06 and ip6[53] & 0x12 = 0x10 and ip6[74:2] & 0xffc3 = 0x0502)' -w "$WORKDIR/sack.pcap" 2> /dev/null & + TCPDUMP_SACK_PID="$!" + + if [ "$1" = 4 ]; then + SERVER_IP="$SERVER_IP4_TUN" + echo "Running IPv4 traffic in the tunnel" + else + SERVER_IP="$SERVER_IP6_TUN" + echo "Running IPv6 traffic in the tunnel" + fi + + sleep 1 # Give tcpdump a second to spin up. + ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \ + -m 80000 > /dev/null + sleep 1 # Give tcpdump a second to process buffered packets. + kill "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID" + wait "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID" + PACKETS_SERVER=$(tcpdump --count -r "$WORKDIR/server.pcap" 2> /dev/null \| cut -d ' ' -f 1) + PACKETS_CLIENT=$(tcpdump --count -r "$WORKDIR/client.pcap" 2> /dev/null \| cut -d ' ' -f 1) + PACKETS_SACK=$(tcpdump --count -r "$WORKDIR/sack.pcap" 2> /dev/null \| cut -d ' ' -f 1) + + echo "Captured BIG TCP RX packets: $PACKETS_SERVER" + echo "Captured BIG TCP TX packets: $PACKETS_CLIENT" + echo "Captured TCP SACK packets: $PACKETS_SACK" + [ "$PACKETS_SERVER" -gt "$PACKETS_THRESHOLD" ] \|\| return 1 + [ "$PACKETS_CLIENT" -gt "$PACKETS_THRESHOLD" ] \|\| return 1 + [ "$PACKETS_SACK" -lt "$(( PACKETS_CLIENT / 2 ))" ] \|\| return 1 +} + +if ! netperf -V &> /dev/null; then + echo "SKIP: Could not run test without netperf tool" + exit "$ksft_skip" +fi + +if ! tcpdump --version &> /dev/null; then + echo "SKIP: Could not run test without tcpdump tool" + exit "$ksft_skip" +fi + +if ! ethtool --version &> /dev/null; then + echo "SKIP: Could not run test without ethtool tool" + exit "$ksft_skip" +fi + +if ! ip link help 2>&1 \| grep gso_ipv4_max_size &> /dev/null; then + echo "SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link" + exit "$ksft_skip" +fi + +WORKDIR=$(mktemp -d) +trap cleanup EXIT +setup +for tunnel in vxlan geneve; do + for tun_family in 4 6; do + for traffic_family in 4 6; do + for csum_offload in on off; do + setup_tunnel "$tunnel" "$tun_family" "$csum_offload" \|\| exit "$?" + do_test "$traffic_family" "$csum_offload" \|\| exit "$?" + cleanup_tunnel + done + done + done +done
3/2	2026/07/07 02:47	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23760 output: 23 thoughts: 854 Thoughts: Fuzzing Strategy for UDP Length Handling with BIG TCP Support Okay, so I'm looking at this patch and it seems like a pretty significant overhaul of UDP length handling, specifically related to supporting BIG TCP, likely for tunneling scenarios like VXLAN and GENEVE. They're introducing `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` in `include/linux/udp.h`, and applying these across a lot of core networking code: Infiniband drivers, Intel Ethernet, Geneve, VXLAN, and core UDP (IPv4 and IPv6) plus offload paths. Essentially, they're replacing direct manipulations of the UDP header length with these new functions. The key thing here is the shift to `udp_set_len_short` and `udp_get_len_short`, or their larger counterparts. This signals a fundamental change – the explicit handling of larger GSO (Generic Segmentation Offload) sizes, likely needed for the aforementioned tunnels to support oversized UDP packets, now becoming possible. Given this, I have a few specific thoughts. First, this is absolutely worth fuzzing. It touches core UDP infrastructure, GRO (Generic Receive Offload), GSO, TSO (Transmit Segment Offload), IPv4, IPv6, and tunnel implementations. The risk of introducing subtle bugs here is substantial, and the impact of those bugs could be significant. Now, let's nail down where to focus my fuzzing efforts. After reviewing the changes, several functions jump out as high-value targets. I need to balance impact with practical considerations. I'd like to avoid the super-hot paths like `udp_rcv` and `udpv6_rcv`. Although they are important, they are less likely to produce unique results and more likely to result in crashes due to complex state and dependencies. However, I should fuzz the following: * `udp_gro_receive` and `udp_gro_complete` (and `udp4_gro_complete` and `udp6_gro_complete`). They're crucial for GRO, where large packets are assembled, so any issues with the new length handling there could cause data corruption or crashes. * `__udp_gso_segment` and `udp_gro_receive_segment`: These are directly involved in segmenting packets for GSO which is the focus of this patch. * `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb`: these are important to test since these directly handle the tunneling logic. * `skb_segment`: A more general function modified by this patch, handling the segmentation logic. I should also check the configuration dependencies. Based on the patch, it seems likely that `CONFIG_NET`, `CONFIG_INET`, `CONFIG_IPV6`, `CONFIG_VXLAN`, `CONFIG_GENEVE`, and `CONFIG_NET_UDP_TUNNEL` will be required. I should ensure that all of these are enabled in my fuzzing environment. The VXLAN and GENEVE drivers are also directly modified, indicating their importance. I might also want to look at `geneve_setup` and `vxlan_setup` since they're setting the `netif_set_tso_max_size(dev, GSO_MAX_SIZE)`. In summary, this requires a targeted fuzzing campaign, focused on a few carefully selected, but high impact functions, and requiring a configuration that supports the relevant protocols and tunneling technologies.
4/2	2026/07/07 02:48	tool	grepper	0m Args: { "Expression": "config VXLAN", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=216=config IPVTAP\n--\ndrivers/net/Kconfig-229-\ndrivers/net/Kconfig:230:config VXLAN\ndrivers/net/Kconfig-231-\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\n" }
5/2	2026/07/07 02:48	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25476 output: 24 thoughts: 9 Thoughts: Okay, here's my summarized thought process, presented as if it were my own: Network Virtualization Protocols: A Quick Assessment Alright, let's see... VXLAN and GENEVE. Hmm, both are solid choices in the realm of network virtualization. They each offer the encapsulation capabilities we need for that overlay networking magic, allowing us to build flexible and scalable virtual networks on top of existing physical infrastructure. They're well-established, and have matured to a level where there's good support and interoperability to consider. No major red flags leap to mind. In the grand scheme of things, they offer the key function we need.
6/2	2026/07/07 02:48	tool	grepper	0m Args: { "Expression": "config GENEVE", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=230=config VXLAN\n--\ndrivers/net/Kconfig-244-\ndrivers/net/Kconfig:245:config GENEVE\ndrivers/net/Kconfig-246-\ttristate \"Generic Network Virtualization Encapsulation\"\n" }
7/2	2026/07/07 02:48	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25727 output: 25 thoughts: 53 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: IPv6 Configuration Concerns Hmm, this situation has me thinking... `CONFIG_IPV6`. That seems like a given, a foundational setting. It's practically standard, isn't it? I'd be surprised if it wasn't already enabled. But then, `CONFIG_NET_FOU` catches my eye. That's immediately relevant. The fact that the code touches `net/ipv4/fou_core.c` and `net/ipv6/fou6.c` is a pretty strong indicator. This implies that the change has implications for both IPv4 and IPv6 traffic encapsulation, which is something I need to carefully consider given its potential impact. It’s got my attention now.
8/2	2026/07/07 02:49	tool	grepper	0m Args: { "Expression": "config NET_FOU", "PathPrefix": "" } Results: { "Output": "net/ipv4/Kconfig=316=config NET_UDP_TUNNEL\n--\nnet/ipv4/Kconfig-320-\nnet/ipv4/Kconfig:321:config NET_FOU\nnet/ipv4/Kconfig-322-\ttristate \"IP: Foo (IP protocols) over UDP\"\n--\nnet/ipv4/Kconfig-329-\nnet/ipv4/Kconfig:330:config NET_FOU_IP_TUNNELS\nnet/ipv4/Kconfig-331-\tbool \"IP: FOU encapsulation of IP tunnels\"\n" }
9/2	2026/07/07 02:49	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26146 output: 25 thoughts: 47 Thoughts: Okay, let's dive into this code. Investigating Potential ESP Security Implications My immediate focus, given modifications to both `net/ipv4/esp4.c` and `net/ipv6/esp6.c`, is the ESP protocol implementation. It's time to check the configuration options, specifically `CONFIG_INET_ESP` and `CONFIG_INET6_ESP`. Any changes to the core ESP implementation, especially in IPv4 and IPv6, warrant a close look at the build configuration to understand which systems this potentially impacts. I need to understand whether these modifications trigger any security considerations for ESP traffic across either protocol, or if the modifications relate to a feature that is not enabled.
10/2	2026/07/07 02:49	tool	grepper	0m Args: { "Expression": "config INET_ESP", "PathPrefix": "" } Results: { "Output": "net/ipv4/Kconfig=339=config INET_AH\n--\nnet/ipv4/Kconfig-353-\nnet/ipv4/Kconfig:354:config INET_ESP\nnet/ipv4/Kconfig-355-\ttristate \"IP: ESP transformation\"\n--\nnet/ipv4/Kconfig-368-\nnet/ipv4/Kconfig:369:config INET_ESP_OFFLOAD\nnet/ipv4/Kconfig-370-\ttristate \"IP: ESP transformation offload\"\n--\nnet/ipv4/Kconfig-381-\nnet/ipv4/Kconfig:382:config INET_ESPINTCP\nnet/ipv4/Kconfig-383-\tbool \"IP: ESP in TCP encapsulation (RFC 8229)\"\n" }
11/2	2026/07/07 02:49	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26578 output: 26 thoughts: 12 Thoughts: Here's a summary of my thought process: Verifying IPv6 ESP Configuration Okay, let's just make sure we haven't missed anything obvious. First, I need to check the `CONFIG_INET6_ESP` configuration option. It's fundamental to IPv6 Encapsulating Security Payload (ESP) operation, so this has to be the first step in ensuring a correct and functional IPv6 security implementation. I need to confirm whether this is enabled. Without it, the whole thing falls apart. No ESP, no protected traffic. Let's make sure it's set correctly.
12/2	2026/07/07 02:49	tool	grepper	0m Args: { "Expression": "config INET6_ESP", "PathPrefix": "" } Results: { "Output": "net/ipv6/Kconfig=47=config INET6_AH\n--\nnet/ipv6/Kconfig-61-\nnet/ipv6/Kconfig:62:config INET6_ESP\nnet/ipv6/Kconfig-63-\ttristate \"IPv6: ESP transformation\"\n--\nnet/ipv6/Kconfig-76-\nnet/ipv6/Kconfig:77:config INET6_ESP_OFFLOAD\nnet/ipv6/Kconfig-78-\ttristate \"IPv6: ESP transformation offload\"\n--\nnet/ipv6/Kconfig-89-\nnet/ipv6/Kconfig:90:config INET6_ESPINTCP\nnet/ipv6/Kconfig-91-\tbool \"IPv6: ESP in TCP encapsulation (RFC 8229)\"\n" }
13/2	2026/07/07 02:49	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26952 output: 24 thoughts: 11 Thoughts: Here's my thought process, as it is: Checking `CONFIG_L2TP` Okay, first things first, let's zero in on `CONFIG_L2TP`. As an expert, I know exactly what this represents. Time to verify its status. Is it enabled? Disabled? Maybe modular? Understanding the current state of this configuration option is the foundation. I need to understand what its impact will be. I'm thinking, "what is the current state? Does this meet the needs?"
14/2	2026/07/07 02:51	tool	grepper	0m Args: { "Expression": "config L2TP", "PathPrefix": "" } Results: { "Output": "net/l2tp/Kconfig-5-\nnet/l2tp/Kconfig:6:menuconfig L2TP\nnet/l2tp/Kconfig-7-\ttristate \"Layer Two Tunneling Protocol (L2TP)\"\n--\nnet/l2tp/Kconfig-35-\nnet/l2tp/Kconfig:36:config L2TP_DEBUGFS\nnet/l2tp/Kconfig-37-\ttristate \"L2TP debugfs support\"\n--\nnet/l2tp/Kconfig-48-\nnet/l2tp/Kconfig:49:config L2TP_V3\nnet/l2tp/Kconfig-50-\tbool \"L2TPv3 support\"\n--\nnet/l2tp/Kconfig-69-\nnet/l2tp/Kconfig:70:config L2TP_IP\nnet/l2tp/Kconfig-71-\ttristate \"L2TP IP encapsulation for L2TPv3\"\n--\nnet/l2tp/Kconfig-86-\nnet/l2tp/Kconfig:87:config L2TP_ETH\nnet/l2tp/Kconfig-88-\ttristate \"L2TP ethernet pseudowire support for L2TPv3\"\n" }
15/2	2026/07/07 02:51	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27413 output: 24 thoughts: 11 Thoughts: Here's my take: Investigating the Configuration Alright, let's dive in. The task before me is clear: I need to ascertain the status of `CONFIG_IP_VS`. Time to check. This is standard operating procedure, really; always start with the base configuration. Knowing the state of this parameter is fundamental to understanding the overall picture and how everything else interacts. This will set the stage for further analysis and decisions. It is the groundwork that must be laid before I can proceed any further.
16/2	2026/07/07 02:51	tool	grepper	0m Args: { "Expression": "config IP_VS", "PathPrefix": "" } Results: { "Output": "net/netfilter/ipvs/Kconfig-4-#\nnet/netfilter/ipvs/Kconfig:5:menuconfig IP_VS\nnet/netfilter/ipvs/Kconfig-6-\ttristate \"IP virtual server support\"\n--\nnet/netfilter/ipvs/Kconfig=286=comment 'IPVS SH scheduler'\nnet/netfilter/ipvs/Kconfig-287-\nnet/netfilter/ipvs/Kconfig:288:config IP_VS_SH_TAB_BITS\nnet/netfilter/ipvs/Kconfig-289-\tint \"IPVS source hashing table size (the Nth power of 2)\"\n--\nnet/netfilter/ipvs/Kconfig=301=comment 'IPVS MH scheduler'\nnet/netfilter/ipvs/Kconfig-302-\nnet/netfilter/ipvs/Kconfig:303:config IP_VS_MH_TAB_INDEX\nnet/netfilter/ipvs/Kconfig-304-\tint \"IPVS maglev hashing table index of size (the prime numbers)\"\n" }
17/2	2026/07/07 02:51	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 27826 output: 22 thoughts: 432 Thoughts: Analyzing the BIG TCP over UDP Tunnel Patch Okay, so this patch is all about enabling BIG TCP over UDP tunnels. Right, let's break down the core of this. The key functions that are being touched are `udp_gro_receive`, `udp_gro_complete`, and its IPv4/IPv6 counterparts (`udp4_gro_complete`, `udp6_gro_complete`), along with the segmentation functions `__udp_gso_segment` and `skb_segment`, and the tunnel transmission functions `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb`. First, I need to understand the impact on performance. I'm thinking, is `udp_gro_receive` a potential hot path? Yup, it's called for every single UDP packet when GRO is involved. On the other hand, `__udp_gso_segment` seems important for UDP GSO packets, while `udp_gro_complete` is crucial for finishing off a UDP GRO packet. And, obviously, `udp_tunnel_xmit_skb` handles the transmission through the UDP tunnel. To keep track, I'll select `__udp_gso_segment`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, and `skb_segment` as my FocusSymbols for closer inspection. I'll also check out `geneve_setup` and `vxlan_setup`, because even though they are just setting the `netif_set_tso_max_size(dev, GSO_MAX_SIZE)` for the interface, it's important to understand the overall context. Now, let's talk about the required configurations. I see that this will rely on `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, and `IP_VS`. I need to ensure all these are enabled. Specifically, I need to verify that `CONFIG_NET_FOU` is sufficient or if `CONFIG_NET_FOU_IP_TUNNELS` is also needed. Looking at the code, it looks like `NET_FOU` is indeed enough for `net/ipv4/fou_core.c` and `net/ipv6/fou6.c`. Finally, since I'm reviewing everything, I'll check `drivers/net/amt.c` to see if `CONFIG_AMT` is relevant here as well.
18/2	2026/07/07 02:51	tool	grepper	0m Args: { "Expression": "config AMT", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=289=config PFCP\n--\ndrivers/net/Kconfig-301-\ndrivers/net/Kconfig:302:config AMT\ndrivers/net/Kconfig-303-\ttristate \"Automatic Multicast Tunneling (AMT)\"\n" }
19/2	2026/07/07 02:52	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 28928 output: 23 thoughts: 21 Thoughts: Here's my take on the thought process, considering I'm an expert: Diving into the Kernel Network Console Alright, let's get down to brass tacks. The objective is clear: dissect the network console functionality within the kernel. My first instinct, as always when I’m getting my bearings, is to zero in on the core implementation. So, my initial thought is to navigate directly to `drivers/net/netconsole.c`. That file is the most likely location for the meat of the network console driver. And, crucially, I need to confirm the configuration option that activates it. So I'm thinking, "Is `CONFIG_NETCONSOLE` defined?" That's my starting point. That macro will quickly tell me if this particular driver is even compiled into the kernel being analyzed. I want to check all of my dependencies, and then move on to checking the functions and variables associated with those dependencies. After that I can determine how this all works.
20/2	2026/07/07 02:52	tool	grepper	0m Args: { "Expression": "config NETCONSOLE", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=318=config MACSEC\n--\ndrivers/net/Kconfig-326-\ndrivers/net/Kconfig:327:config NETCONSOLE\ndrivers/net/Kconfig-328-\ttristate \"Network console logging support\"\n--\ndrivers/net/Kconfig-333-\ndrivers/net/Kconfig:334:config NETCONSOLE_DYNAMIC\ndrivers/net/Kconfig-335-\tbool \"Dynamic reconfiguration of logging targets\"\n--\ndrivers/net/Kconfig-344-\ndrivers/net/Kconfig:345:config NETCONSOLE_EXTENDED_LOG\ndrivers/net/Kconfig-346-\tbool \"Set kernel extended message by default\"\n--\ndrivers/net/Kconfig-354-\ndrivers/net/Kconfig:355:config NETCONSOLE_PREPEND_RELEASE\ndrivers/net/Kconfig-356-\tbool \"Prepend kernel release version in the message by default\"\n" }
21/2	2026/07/07 02:52	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 29423 output: 25 thoughts: 25 Thoughts: Here's my take on the thought process, as if I were the one thinking it: Diving into WireGuard Receive Path Alright, time to dig into the WireGuard receive path. I need to understand how the data's flowing. My first stop, as always, will be the source code. Let's see... I'm focusing on the receive side, so `drivers/net/wireguard/receive.c` seems like the logical place to start. And, of course, I should make absolutely certain that `CONFIG_WIREGUARD` is enabled, because if that isn't true, I'm wasting my time looking into code that won't even be compiled. Let's just double-check that. That's always my first step to be sure I am looking at the code that is actually run.
22/2	2026/07/07 02:52	tool	grepper	0m Args: { "Expression": "config WIREGUARD", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=59=config DUMMY\n--\ndrivers/net/Kconfig-73-\ndrivers/net/Kconfig:74:config WIREGUARD\ndrivers/net/Kconfig-75-\ttristate \"WireGuard secure network tunnel\"\n--\ndrivers/net/Kconfig-91-\ndrivers/net/Kconfig:92:config WIREGUARD_DEBUG\ndrivers/net/Kconfig-93-\tbool \"Debugging checks and verbose messages\"\n" }
23/2	2026/07/07 02:53	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 29781 output: 30 thoughts: 31 Thoughts: Here's my take on the thought process, as if it were my own: Investigating the UDP Neighbor Header Compression Implementation Okay, time to dive into the UDP Neighbor Header Compression code. First things first: let's zero in on `net/6lowpan/nhc_udp.c`. That's where I expect to find the meat of this implementation. And I need to be absolutely sure that the configuration is enabled, so I'll double-check that `CONFIG_6LOWPAN_NHC_UDP` is set. Gotta make sure it's compiled in before I waste time looking at something that isn't even part of the current build. This is standard procedure; always start by verifying the prerequisites before you start analyzing the core functionality.
24/2	2026/07/07 02:53	tool	grepper	0m Args: { "Expression": "config 6LOWPAN_NHC_UDP", "PathPrefix": "" } Results: { "Output": "net/6lowpan/Kconfig=59=config 6LOWPAN_NHC_ROUTING\n--\nnet/6lowpan/Kconfig-64-\nnet/6lowpan/Kconfig:65:config 6LOWPAN_NHC_UDP\nnet/6lowpan/Kconfig-66-\ttristate \"UDP Header Support\"\n" }
25/2	2026/07/07 02:53	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 30101 output: 29 thoughts: 39 Thoughts: Here's a summary of my thought process, as requested: Diving into the SNMP NAT Implementation Okay, so I need to understand how SNMP traffic is being handled in this NAT setup. My first port of call is going to be the code related to the `nf_nat_snmp_basic` module, specifically `net/ipv4/netfilter/nf_nat_snmp_basic_main.c`. The fact that it's in the `netfilter` directory tells me it's operating at the kernel's network level, which is what I'd expect. Now, I need to make sure the relevant functionality is even enabled in this build, so I need to verify that `CONFIG_NF_NAT_SNMP_BASIC` is defined. This will be the starting point to understand the specifics of this NAT implementation.
26/2	2026/07/07 02:53	tool	grepper	0m Args: { "Expression": "config NF_NAT_SNMP_BASIC", "PathPrefix": "" } Results: { "Output": "net/ipv4/netfilter/Kconfig=99=if NF_NAT\nnet/ipv4/netfilter/Kconfig:100:config NF_NAT_SNMP_BASIC\nnet/ipv4/netfilter/Kconfig-101-\ttristate \"Basic SNMP-ALG support\"\n" }
27/2	2026/07/07 02:54	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 30434 output: 24 thoughts: 85 Thoughts: Here's my thought process, as it stands: Navigating Kernel Configuration Options Okay, so I'm thinking about something related to network traffic and need to figure out which kernel configuration options are relevant. My first instinct is to check out the conntrack side of things, specifically the UDP protocol handler. I should probably start by examining `net/netfilter/nf_conntrack_proto_udp.c` to see if `CONFIG_NF_CT_PROTO_UDP` is enabled. Though, honestly, often the dependency is just the broader `CONFIG_NF_CONNTRACK` option. Then, since I'm already in this investigative mood, I'll move over to the XFRM subsystem. Given the context, the NAT keepalive functionality is likely to be relevant. Let's see if the configuration option `CONFIG_XFRM_NAT_KEEPALIVE` is enabled in `net/xfrm/xfrm_nat_keepalive.c`. That should give me some direction.
28/2	2026/07/07 02:54	tool	grepper	0m Args: { "Expression": "config XFRM", "PathPrefix": "" } Results: { "Output": "net/xfrm/Kconfig-4-#\nnet/xfrm/Kconfig:5:config XFRM\nnet/xfrm/Kconfig-6-\tbool\n--\nnet/xfrm/Kconfig-10-\nnet/xfrm/Kconfig:11:config XFRM_OFFLOAD\nnet/xfrm/Kconfig-12-\tbool\nnet/xfrm/Kconfig-13-\nnet/xfrm/Kconfig:14:config XFRM_ALGO\nnet/xfrm/Kconfig-15-\ttristate\n--\nnet/xfrm/Kconfig=22=if INET\nnet/xfrm/Kconfig:23:config XFRM_USER\nnet/xfrm/Kconfig-24-\ttristate \"Transformation user configuration interface\"\n--\nnet/xfrm/Kconfig-31-\nnet/xfrm/Kconfig:32:config XFRM_USER_COMPAT\nnet/xfrm/Kconfig-33-\ttristate \"Compatible ABI support\"\n--\nnet/xfrm/Kconfig-42-\nnet/xfrm/Kconfig:43:config XFRM_INTERFACE\nnet/xfrm/Kconfig-44-\ttristate \"Transformation virtual interface\"\n--\nnet/xfrm/Kconfig-50-\nnet/xfrm/Kconfig:51:config XFRM_SUB_POLICY\nnet/xfrm/Kconfig-52-\tbool \"Transformation sub policy support\"\n--\nnet/xfrm/Kconfig-60-\nnet/xfrm/Kconfig:61:config XFRM_MIGRATE\nnet/xfrm/Kconfig-62-\tbool \"Transformation migrate database\"\n--\nnet/xfrm/Kconfig-71-\nnet/xfrm/Kconfig:72:config XFRM_STATISTICS\nnet/xfrm/Kconfig-73-\tbool \"Transformation statistics\"\n--\nnet/xfrm/Kconfig-83-# RFC 8221 lists as MUST be implemented.\nnet/xfrm/Kconfig:84:config XFRM_AH\nnet/xfrm/Kconfig-85-\ttristate\n--\nnet/xfrm/Kconfig-92-# algorithms that RFC 8221 lists as MUST be implemented.\nnet/xfrm/Kconfig:93:config XFRM_ESP\nnet/xfrm/Kconfig-94-\ttristate\n--\nnet/xfrm/Kconfig-105-\nnet/xfrm/Kconfig:106:config XFRM_IPCOMP\nnet/xfrm/Kconfig-107-\ttristate\n--\nnet/xfrm/Kconfig=125=config NET_KEY_MIGRATE\n--\nnet/xfrm/Kconfig-140-\nnet/xfrm/Kconfig:141:config XFRM_IPTFS\nnet/xfrm/Kconfig-142-\ttristate \"IPsec IP-TFS/AGGFRAG (RFC 9347) encapsulation support\"\n--\nnet/xfrm/Kconfig-156-\nnet/xfrm/Kconfig:157:config XFRM_ESPINTCP\nnet/xfrm/Kconfig-158-\tbool\n" }
29/2	2026/07/07 02:54	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 31551 output: 27 thoughts: 43 Thoughts: Here's my take on those thoughts: XFRM & the IPsec Connection Okay, so XFRM is basically baked in if IPsec is enabled. That makes sense, right? They're tightly coupled. Now, I want to drill down a bit further. Let's see how the checksum offload is being handled, so I'm going to take a look at `net/sched/act_csum.c` and specifically, I'm going to double-check the `CONFIG_NET_ACT_CSUM` config option. I need to understand if the checksum calculations are being offloaded, or if other considerations are at play here.
30/2	2026/07/07 02:54	tool	grepper	0m Args: { "Expression": "config NET_ACT_CSUM", "PathPrefix": "" } Results: { "Output": "net/sched/Kconfig=797=config NET_ACT_SKBEDIT\n--\nnet/sched/Kconfig-807-\nnet/sched/Kconfig:808:config NET_ACT_CSUM\nnet/sched/Kconfig-809-\ttristate \"Checksum Updating\"\n" }
31/2	2026/07/07 02:54	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 31849 output: 26 thoughts: 34 Thoughts: Here's my analysis of the provided thought process, tailored for an expert audience: Diving into the RDMA RXE Implementation Okay, so the prompt directs me to investigate `drivers/infiniband/sw/rxe/rxe_net.c`. This strongly suggests an interest in the software-based RDMA over Ethernet (RXE) implementation within the Linux kernel's Infiniband subsystem. The key here is the conditional compilation flag: `CONFIG_RDMA_RXE`. My immediate thought is, "Right, we're likely examining a section of code specifically enabled when RXE support is configured." This points to functionality, logic, and potential optimizations that are only relevant when using software-emulated RDMA over standard Ethernet, not hardware-accelerated RDMA. I’ll be looking for configuration-specific code blocks, initialization sequences, and any conditional branches or macros tied directly to `CONFIG_RDMA_RXE`. Knowing the context, I expect to see networking-related structures and functions interwoven with the core RDMA concepts of verbs, completion queues, and memory registration – all adapted for Ethernet's transport. I'll need to pay close attention to the interaction between the RXE layer and the generic network stack, particularly the handling of Ethernet frames, data encapsulation, and addressing.
32/2	2026/07/07 02:54	tool	grepper	0m Args: { "Expression": "config RDMA_RXE", "PathPrefix": "" } Results: { "Output": "drivers/infiniband/sw/rxe/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/sw/rxe/Kconfig:2:config RDMA_RXE\ndrivers/infiniband/sw/rxe/Kconfig-3-\ttristate \"Software RDMA over Ethernet (RoCE) driver\"\n" }
33/2	2026/07/07 02:55	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32287 output: 25 thoughts: 26 Thoughts: Here's my take on the thought process, summarized as you requested: Navigating the Netdevsim Landscape Okay, so we're diving into this `netdevsim` stuff. My initial thought is to zero in on a potential area of interest within the kernel source code. Specifically, let's start with `drivers/net/netdevsim/psp.c`. This seems like a reasonable place to begin, given the likely interactions involved. And, since we're dealing with netdevsim, I'm making a mental note to check the `CONFIG_NETDEVSIM` compile-time option to ensure it's enabled. That flag will be key to understanding whether this code path is even relevant to the current build configuration. It’s the usual sanity check before getting too deep, to avoid wasting time looking at irrelevant code.
34/2	2026/07/07 02:55	tool	grepper	0m Args: { "Expression": "config NETDEVSIM", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=602=source \"drivers/net/hyperv/Kconfig\"\ndrivers/net/Kconfig-603-\ndrivers/net/Kconfig:604:config NETDEVSIM\ndrivers/net/Kconfig-605-\ttristate \"Simulated networking device\"\n" }
35/2	2026/07/07 02:55	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32604 output: 22 thoughts: 93 Thoughts: Here's my thought process, as if I were considering this code: Navigating the PSP Driver Source Okay, so I need to track down something related to the PSP driver and its configuration. My initial instinct is to go straight to `drivers/net/psp/psp_main.c`, assuming it's a typical driver structure. But hold on, the directory structure in Linux can be a bit… flexible. Wait, is it `net/psp/psp_main.c`? Or even just `psp_main.c`? No, no, the diff I'm reviewing explicitly lists `net/psp/psp_main.c`. Good, got it. Now, the main question: is this PSP feature enabled via a `CONFIG_PSP` define? Time to verify that this configuration option exists within this file. Let's look for `CONFIG_PSP`.
36/2	2026/07/07 02:55	tool	grepper	0m Error: no matches Args: { "Expression": "config PSP", "PathPrefix": "" } Results: { "error": "no matches" }
37/2	2026/07/07 02:55	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32920 output: 24 thoughts: 33 Thoughts: Here's my thought process, as if I were considering this code: Navigating the Network Stack Okay, so we're looking at `net/psp/psp_main.c`. My first move? I'm immediately thinking, "Where does this fit in the larger network picture?" Specifically, given the "psp" prefix, I need to understand what this component is all about. The easiest place to start for this kind of context is the configuration system. I'd head straight for either `net/psp/Kconfig` (assuming there's a specific configuration file for the PSP-related code) or, if that doesn't exist or doesn't provide enough top-level context, I'll check the parent directory's `net/Kconfig`. These are the configuration files that'll tell me if this is a standalone feature, a dependent module, or part of a larger, conditionally-compiled system. That's where the architectural overview usually lives. They'll tell me if this is a feature I might be able to disable or if it’s a dependency of another network component. Understanding those Kconfig files is going to be crucial to understanding the role of this `psp_main.c` file within the overall network stack.
38/2	2026/07/07 02:55	tool	grepper	0m Error: no matches Args: { "Expression": "config PSP", "PathPrefix": "net/" } Results: { "error": "no matches" }
39/2	2026/07/07 02:55	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33256 output: 26 thoughts: 23 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Investigating a Potentially Obscured Dependency Hmm, `PSP`... that term feels a bit incomplete, like it's a piece of a larger puzzle. Instead of jumping to conclusions, my first instinct is to see if `PSP` is a component within something more clearly defined. So, let's go straight to the source: the `net/psp/Makefile`. The makefile is usually the best place to find dependencies, build configurations, and, ideally, any context clues about what `PSP` actually refers to in this particular project. From there, I can begin to triangulate what `PSP` is, what it does, and how it fits into the overall architecture.
40/2	2026/07/07 02:56	tool	grepper	0m Args: { "Expression": "psp", "PathPrefix": "net/psp/Makefile" } Results: { "Output": "net/psp/Makefile-2-\nnet/psp/Makefile:3:obj-$(CONFIG_INET_PSP) += psp.o\nnet/psp/Makefile-4-\nnet/psp/Makefile:5:psp-y := psp_main.o psp_nl.o psp_sock.o psp-nl-gen.o\n" }
41/2	2026/07/07 02:56	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33561 output: 25 thoughts: 7 Thoughts: Okay, here's my interpretation of that: My Initial Reaction to `CONFIG_INET_PSP` Right, `CONFIG_INET_PSP`. Instantly, my mind jumps to the relevant kernel configuration option. This is about Packet Scheduling, specifically for the "Priority Scheduling Protocol" within the Linux kernel's networking stack. I immediately consider the implications. Enabling this would introduce a mechanism to prioritize network traffic based on certain criteria, likely defined through traffic control rules (tc). My immediate thought is, what are the use cases? Where would this be valuable? Are we talking about prioritizing latency-sensitive applications like VoIP or video conferencing? Or perhaps prioritizing control traffic in an industrial environment? What about differentiating between interactive and background traffic on the network? I also need to think about how this interacts with other queuing disciplines. Does PSP play nicely with things like HTB (Hierarchical Token Bucket), FQ_CODEL, or even the basic FIFO (First-In, First-Out) queuing? I start to formulate questions. What is the overhead? Does enabling this significantly impact CPU utilization? Is it worth the complexity of setting up and maintaining the traffic control rules? What version of the kernel are we working with? PSP may have evolved or improved in more recent versions. And, is this an isolated configuration, or is it part of a larger network setup or system architecture? Understanding the context is crucial. Ultimately, my assessment hinges on the specific needs of the network environment and the potential trade-offs between performance, complexity, and resource consumption. I need more information to form a conclusive judgment.
42/2	2026/07/07 02:57	tool	grepper	0m Args: { "Expression": "config INET_PSP", "PathPrefix": "" } Results: { "Output": "net/psp/Kconfig-4-#\nnet/psp/Kconfig:5:config INET_PSP\nnet/psp/Kconfig-6-\tbool \"PSP Security Protocol support\"\n" }
43/2	2026/07/07 02:57	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33977 output: 38 thoughts: 1164 Thoughts: Refining the Target for Fuzzing: UDP Offload and Tunneling Okay, so I'm thinking about how to best approach fuzzing around UDP-related network functionality, specifically focusing on areas that have seen recent changes. The goal is to maximize the chances of uncovering potential bugs introduced by these modifications. `INET_PSP` is the trigger, the thing I'm trying to validate. First, I quickly scan the known hardware driver landscape. I mentally tick through common Intel drivers (`i40e`, `iavf`, `ice`, `idpf`), Marvell (`octeontx2`), Mellanox (`mlx5`), and others (`sfc`, `stmmac`). I don't need every single driver, but I do note the importance of including `NETDEVSIM`, a crucial software driver that I can readily test in a virtual environment. `RDMA_RXE`, a software RoCE driver, is also worth keeping in mind for completeness. Next, I need to define the relevant configurations to be enabled in order to exercise the right parts of the code. I'll make sure to enable features like `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, `IP_VS`, `AMT`, `WIREGUARD`, `6LOWPAN_NHC_UDP`, `NF_NAT_SNMP_BASIC`, `NET_ACT_CSUM`, and especially `RDMA_RXE` and `NETDEVSIM` alongside `INET_PSP`. Now, diving into the code, I head straight for the UDP offload paths: `net/ipv4/udp_offload.c` and `net/ipv6/udp_offload.c`. I have a shortlist of functions to look at: `__skb_udp_tunnel_segment`, `__udp_gso_segment_list`, `__udp_gso_segment`, `udp_gro_receive_segment`, `udp_gro_receive`, `udp_gro_complete_segment`, `udp_gro_complete`, `udp4_gro_complete`, and `udp6_gro_complete`. From here, I'm forming my list of `FocusSymbols`. I start with: `__udp_gso_segment`, `udp_gro_receive`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `__skb_udp_tunnel_segment`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `skb_segment`, and `tso_build_hdr`. But now I do a quick sanity check. `skb_segment` is called for all GSO packets. It's too generic and likely a very hot path. I don't want to get distracted by things that are only marginally changed. `udp_gro_receive` is in the same boat; very hot, but maybe not the best place to focus. We want to find new, or modified paths. So, I re-evaluate. I think `__udp_gso_segment` is more promising, and also `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb` are good choices. `udp_gro_complete`, `udp4_gro_complete`, and `udp6_gro_complete` also look relevant. I briefly glance at `udp_set_len_short` and `udp_get_len_short` in `include/linux/udp.h` – inline functions, so probably not the core of the problem. Then, I check `net/ipv4/udp.c` and `net/ipv6/udp.c`. `udp_send_skb`, `udp_v6_send_skb`, `udp_rcv`, and `udpv6_rcv` are all modified. They are also super hot paths. We'll avoid them here to avoid skewing our coverage, but we absolutely know that functional changes were introduced there. In short, there is a clear target here; `WorthFuzzing` is definitely true. So, my final refined list of `FocusSymbols` will be: `__udp_gso_segment`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `__skb_udp_tunnel_segment`, and `udp_gro_receive_segment`. This should get us where we want to be. I'll take a quick look at `udp_gro_receive_segment` in `
44/2	2026/07/07 02:57	tool	grepper	0m Args: { "Expression": "udp_gro_receive_segment", "PathPrefix": "net/ipv4/udp_offload.c" } Results: { "Output": "net/ipv4/udp_offload.c=631=static struct sk_buff udp4_ufo_fragment(struct sk_buff skb,\n--\nnet/ipv4/udp_offload.c-692-#define UDP_GRO_CNT_MAX 64\nnet/ipv4/udp_offload.c:693:static struct sk_buff udp_gro_receive_segment(struct list_head head,\nnet/ipv4/udp_offload.c-694-\t\t\t\t\t struct sk_buff skb)\n--\nnet/ipv4/udp_offload.c=774=struct sk_buff udp_gro_receive(struct list_head head, struct sk_buff skb,\n--\nnet/ipv4/udp_offload.c-806-\t\t (sk \u0026\u0026 udp_test_bit(GRO_ENABLED, sk)) \|\| NAPI_GRO_CB(skb)-\u003eis_flist)\nnet/ipv4/udp_offload.c:807:\t\t\treturn call_gro_receive(udp_gro_receive_segment, head, skb);\nnet/ipv4/udp_offload.c-808-\n" }
45/2	2026/07/07 02:57	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 36502 output: 35 thoughts: 62 Thoughts: Okay, here's my take on those thoughts, framed as my own: UDP GRO and Tunneling Considerations Alright, looking at this, `udp_gro_receive_segment` seems like a solid starting point for investigation. My initial intuition is leading me there, and I want to confirm that suspicion. I need to dive into the core FOu code next, specifically, `net/ipv4/fou_core.c` and `net/ipv6/fou6.c`. I'm particularly interested in the functions responsible for building the UDP headers, so I'll be looking closely at `fou_build_udp` (IPv4) and `fou6_build_udp` (IPv6). I need to understand how these functions interact with the GRO path, and if they're already taking the appropriate steps that I might be looking to replicate. Understanding their behavior is a prerequisite to making any changes.
46/2	2026/07/07 02:57	tool	grepper	0m Args: { "Expression": "fou_build_udp", "PathPrefix": "net/ipv4/fou_core.c" } Results: { "Output": "net/ipv4/fou_core.c=1027=EXPORT_SYMBOL(__gue_build_header);\n--\nnet/ipv4/fou_core.c-1030-\nnet/ipv4/fou_core.c:1031:static void fou_build_udp(struct sk_buff skb, struct ip_tunnel_encap e,\nnet/ipv4/fou_core.c-1032-\t\t\t struct flowi4 fl4, u8 protocol, __be16 sport)\n--\nnet/ipv4/fou_core.c=1050=static int fou_build_header(struct sk_buff skb, struct ip_tunnel_encap e,\n--\nnet/ipv4/fou_core.c-1061-\nnet/ipv4/fou_core.c:1062:\tfou_build_udp(skb, e, fl4, protocol, sport);\nnet/ipv4/fou_core.c-1063-\n--\nnet/ipv4/fou_core.c=1067=static int gue_build_header(struct sk_buff skb, struct ip_tunnel_encap e,\n--\nnet/ipv4/fou_core.c-1078-\nnet/ipv4/fou_core.c:1079:\tfou_build_udp(skb, e, fl4, protocol, sport);\nnet/ipv4/fou_core.c-1080-\n" }
47/2	2026/07/07 02:57	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 37167 output: 37 thoughts: 71 Thoughts: Here's my thinking: UDP Encapsulation Strategy Okay, I'm trying to figure out the best approach for building UDP-encapsulated packets. Given the context, `fou_build_udp` and `fou6_build_udp` immediately jump out as strong possibilities, they are the obvious candidates. Now, to refine my understanding, I need to see how these functions are implemented. I'll take a look at the ESP code; specifically, I need to investigate the interaction with UDP encapsulation within the ESP context. I'll start by checking the implementations of the relevant ESP output functions: `net/ipv4/esp4.c` and `net/ipv6/esp6.c`, looking for the relevant functions to build these UDP encapsulated packets, which I suspect are `esp_output_udp_encap` and `esp6_output_udp_encap`. This should give me the low-level details I need.
48/2	2026/07/07 02:58	tool	grepper	0m Args: { "Expression": "esp_output_udp_encap", "PathPrefix": "net/ipv4/esp4.c" } Results: { "Output": "net/ipv4/esp4.c=301=static void esp_output_done_esn(void data, int err)\n--\nnet/ipv4/esp4.c-308-\nnet/ipv4/esp4.c:309:static struct ip_esp_hdr esp_output_udp_encap(struct sk_buff skb,\nnet/ipv4/esp4.c-310-\t\t\t\t\t int encap_type,\n--\nnet/ipv4/esp4.c-329-\t/ For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload\nnet/ipv4/esp4.c:330:\t * data path, which means that esp_output_udp_encap is called outside of the XFRM stack.\nnet/ipv4/esp4.c-331-\t * In this case, the mac header doesn't point to the IPv4 protocol field, so don't set it.\n--\nnet/ipv4/esp4.c=376=static int esp_output_encap(struct xfrm_state x, struct sk_buff skb,\n--\nnet/ipv4/esp4.c-392-\tcase UDP_ENCAP_ESPINUDP:\nnet/ipv4/esp4.c:393:\t\tesph = esp_output_udp_encap(skb, encap_type, esp, sport, dport);\nnet/ipv4/esp4.c-394-\t\tbreak;\n" }
49/2	2026/07/07 02:58	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 37859 output: 41 thoughts: 57 Thoughts: Here's my thought process, as if I were considering this issue: Considering UDP Encapsulation Options Okay, so I'm looking at UDP encapsulation methods. Based on my experience, I think `esp_output_udp_encap` and `esp6_output_udp_encap` are strong contenders here. They're likely designed for the kind of encapsulation I need. Just to be thorough, I should also check out `net/l2tp/l2tp_core.c`. Sometimes, similar functionality is buried in unexpected places. Specifically, I'll pay close attention to `l2tp_xmit_core`. It's possible there are relevant code snippets or architectural insights there that I might be able to leverage. I'll need to assess the applicability of what I find.
50/2	2026/07/07 02:58	tool	grepper	0m Args: { "Expression": "l2tp_xmit_core", "PathPrefix": "net/l2tp/l2tp_core.c" } Results: { "Output": "net/l2tp/l2tp_core.c=1209=static int l2tp_xmit_queue(struct l2tp_tunnel tunnel, struct sk_buff skb, struct flowi fl)\n--\nnet/l2tp/l2tp_core.c-1224-\nnet/l2tp/l2tp_core.c:1225:static int l2tp_xmit_core(struct l2tp_session session, struct sk_buff skb, unsigned int len)\nnet/l2tp/l2tp_core.c-1226-{\n--\nnet/l2tp/l2tp_core.c=1328=int l2tp_xmit_skb(struct l2tp_session session, struct sk_buff skb)\n--\nnet/l2tp/l2tp_core.c-1332-\nnet/l2tp/l2tp_core.c:1333:\tret = l2tp_xmit_core(session, skb, \u0026len);\nnet/l2tp/l2tp_core.c-1334-\tif (ret == NET_XMIT_SUCCESS) {\n" }
51/2	2026/07/07 02:58	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 38437 output: 43 thoughts: 48 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Initial Assessment: Transmission Candidate Analysis Right, let's see, based on what I know and experience, `l2tp_xmit_core` feels like a strong contender here. I think it's where I need to start. It just feels like the place to look for that bit of functionality, or at least a good reference point for the low-level transmission logic. Now, let's double-check my gut feeling and see how this all intersects with something like `net/netfilter/ipvs/ip_vs_xmit.c`. Particularly interested in digging into how they handle encapsulation here, so let's check out `ipvs_gue_encap`. Always better to confirm and compare against a known, related module. I'll need to see how they're handling things.
52/2	2026/07/07 02:58	tool	grepper	0m Args: { "Expression": "ipvs_gue_encap", "PathPrefix": "net/netfilter/ipvs/ip_vs_xmit.c" } Results: { "Output": "net/netfilter/ipvs/ip_vs_xmit.c=1037=static int\nnet/netfilter/ipvs/ip_vs_xmit.c:1038:ipvs_gue_encap(struct net net, struct sk_buff skb,\nnet/netfilter/ipvs/ip_vs_xmit.c-1039-\t struct ip_vs_conn cp, __u8 next_protocol)\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=1149=ip_vs_tunnel_xmit(struct sk_buff skb, struct ip_vs_conn cp,\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-1246-\nnet/netfilter/ipvs/ip_vs_xmit.c:1247:\t\tif (ipvs_gue_encap(net, skb, cp, \u0026next_protocol))\nnet/netfilter/ipvs/ip_vs_xmit.c-1248-\t\t\tgoto tx_error;\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=1294=ip_vs_tunnel_xmit_v6(struct sk_buff skb, struct ip_vs_conn cp,\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-1389-\nnet/netfilter/ipvs/ip_vs_xmit.c:1390:\t\tif (ipvs_gue_encap(net, skb, cp, \u0026next_protocol))\nnet/netfilter/ipvs/ip_vs_xmit.c-1391-\t\t\tgoto tx_error;\n" }
53/2	2026/07/07 02:58	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 39148 output: 34 thoughts: 38 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Considering IPVS and TSO for Network Optimization Hmm, `ipvs_gue_encap`… that's got some potential. I'm thinking about network performance optimization, and tunneling is often a good area to examine. IPVS, especially with Generic UDP Encapsulation, that could be a significant player here. Alright, let's dive deeper. I'm going to shift focus to `net/core/tso.c` now. This is where the core Transmission Segmentation Offload (TSO) functionality resides, crucial for handling large packets efficiently. Specifically, I need to check out `tso_build_hdr`. Understanding how the headers are constructed during TSO is key to identifying any bottlenecks or potential improvements related to IPVS encapsulation and how it interacts with TSO.
54/2	2026/07/07 02:59	tool	grepper	0m Args: { "Expression": "tso_build_hdr", "PathPrefix": "net/core/tso.c" } Results: { "Output": "net/core/tso.c-8-\nnet/core/tso.c:9:void tso_build_hdr(const struct sk_buff skb, char hdr, struct tso_t *tso,\nnet/core/tso.c-10-\t\t int size, bool is_last)\n--\nnet/core/tso.c-45-}\nnet/core/tso.c:46:EXPORT_SYMBOL(tso_build_hdr);\nnet/core/tso.c-47-\n" }
55/2	2026/07/07 02:59	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 39550 output: 32 thoughts: 35 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Investigating a Potential Header Building Strategy Alright, given the context, `tso_build_hdr` looks like a strong starting point for the header construction. It's a natural candidate for this kind of operation. Now, to be thorough, I should check the implementation details, specifically how segmentation is handled within the kernel. Let's dive into `net/core/skbuff.c`. I need to understand how the system manages the network buffers at the core level. Specifically, I'm thinking about how the system handles segmentation, so I want to understand what's in `skb_segment`. This should reveal some of the inner workings.
56/2	2026/07/07 02:59	tool	grepper	0m Args: { "Expression": "skb_segment", "PathPrefix": "net/core/skbuff.c" } Results: { "Output": "net/core/skbuff.c=4656=static inline skb_frag_t skb_head_frag_to_page_desc(struct sk_buff frag_skb)\n--\nnet/core/skbuff.c-4667-\nnet/core/skbuff.c:4668:struct sk_buff skb_segment_list(struct sk_buff skb,\nnet/core/skbuff.c-4669-\t\t\t\t netdev_features_t features,\n--\nnet/core/skbuff.c-4759-}\nnet/core/skbuff.c:4760:EXPORT_SYMBOL_GPL(skb_segment_list);\nnet/core/skbuff.c-4761-\nnet/core/skbuff.c-4762-/\nnet/core/skbuff.c:4763: \tskb_segment - Perform protocol segmentation on skb.\nnet/core/skbuff.c-4764- \t@head_skb: buffer to segment\n--\nnet/core/skbuff.c-4770- /\nnet/core/skbuff.c:4771:struct sk_buff skb_segment(struct sk_buff head_skb,\nnet/core/skbuff.c-4772-\t\t\t netdev_features_t features)\n--\nnet/core/skbuff.c-5027-\t\t\t\tnet_warn_ratelimited(\nnet/core/skbuff.c:5028:\t\t\t\t\t\"skb_segment: too many frags: %u %u\\n\",\nnet/core/skbuff.c-5029-\t\t\t\t\tpos, mss);\n--\nnet/core/skbuff.c-5123-}\nnet/core/skbuff.c:5124:EXPORT_SYMBOL_GPL(skb_segment);\nnet/core/skbuff.c-5125-\n" }
57/2	2026/07/07 02:59	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 40261 output: 38 thoughts: 39 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: UDP Segmentation Exploration Alright, based on the problem I'm tackling, `skb_segment` is looking like a pretty solid starting point. It's the standard function for packet segmentation in the kernel, and it's always a good idea to see if the core utilities can handle the issue. Let's dive into the UDP offload implementation. I'll need to reference `net/ipv4/udp_offload.c` to understand how the UDP stack handles segmentation, especially for GSO. I'm particularly interested in that `__udp_gso_segment` function. I anticipate it might be the core logic for the UDP specific segmentation. I'll need to thoroughly examine its arguments, and how it interacts with other networking layers.
58/2	2026/07/07 02:59	tool	grepper	0m Args: { "Expression": "__udp_gso_segment", "PathPrefix": "net/ipv4/udp_offload.c" } Results: { "Output": "net/ipv4/udp_offload.c=429=static struct sk_buff __udpv6_gso_segment_list_csum(struct sk_buff segs)\n--\nnet/ipv4/udp_offload.c-460-\nnet/ipv4/udp_offload.c:461:static struct sk_buff __udp_gso_segment_list(struct sk_buff skb,\nnet/ipv4/udp_offload.c-462-\t\t\t\t\t netdev_features_t features,\n--\nnet/ipv4/udp_offload.c-478-\nnet/ipv4/udp_offload.c:479:struct sk_buff __udp_gso_segment(struct sk_buff gso_skb,\nnet/ipv4/udp_offload.c-480-\t\t\t\t netdev_features_t features, bool is_ipv6)\n--\nnet/ipv4/udp_offload.c-517-\t\t !(skb_shinfo(gso_skb)-\u003egso_type \u0026 SKB_GSO_DODGY))\nnet/ipv4/udp_offload.c:518:\t\t\treturn __udp_gso_segment_list(gso_skb, features, is_ipv6);\nnet/ipv4/udp_offload.c-519-\n--\nnet/ipv4/udp_offload.c=631=static struct sk_buff udp4_ufo_fragment(struct sk_buff skb,\n--\nnet/ipv4/udp_offload.c-653-\tif (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_L4)\nnet/ipv4/udp_offload.c:654:\t\treturn __udp_gso_segment(skb, features, false);\nnet/ipv4/udp_offload.c-655-\n" }
59/2	2026/07/07 02:59	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 41005 output: 38 thoughts: 53 Thoughts: Okay, here's my take on those Linux kernel function names and their potential relevance, as if I'm processing them myself: UDP Offload Function Investigation Alright, looking at this code, my initial gut reaction is that `__udp_gso_segment` and `__udp_gso_segment_list` are strong possibilities for what I'm interested in. The naming strongly implies they're involved in Generic Segmentation Offload (GSO) specifically for UDP. That's exactly the area I need to understand better for this networking optimization I'm working on. Let's dig in a bit further to confirm that suspicion. The next logical step would be to see how these functions are being used. Specifically, I'll check in `net/ipv6/udp_offload.c`. I expect to find some of the IPv6 UDP offload logic there, which should give me context for understanding the GSO functions. I see `udp6_ufo_fragment`, which is a key part of the UFO/GSO path and what I expect to be near related code.
60/2	2026/07/07 02:59	tool	grepper	0m Args: { "Expression": "udp6_ufo_fragment", "PathPrefix": "net/ipv6/udp_offload.c" } Results: { "Output": "net/ipv6/udp_offload.c-18-\nnet/ipv6/udp_offload.c:19:static struct sk_buff udp6_ufo_fragment(struct sk_buff skb,\nnet/ipv6/udp_offload.c-20-\t\t\t\t\t netdev_features_t features)\n--\nnet/ipv6/udp_offload.c=191=int __init udpv6_offload_init(void)\n--\nnet/ipv6/udp_offload.c-194-\t\t.callbacks = {\nnet/ipv6/udp_offload.c:195:\t\t\t.gso_segment\t=\tudp6_ufo_fragment,\nnet/ipv6/udp_offload.c-196-\t\t\t.gro_receive\t=\tudp6_gro_receive,\n" }
61/2	2026/07/07 02:59	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 41543 output: 41 thoughts: 50 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person: UDP Fragmentation & Generic Segmentation Offload - Delving into the Kernel Right, so `udp6_ufo_fragment` is calling `__udp_gso_segment`. That immediately flags something interesting. I need to understand how the Userland Fragmentation Offload (UFO) is interacting with Generic Segmentation Offload (GSO) for UDPv6. The potential performance implications are obvious; any inefficiencies here would be multiplied, especially at scale. My next stop is definitely `net/ipv4/udp_tunnel_core.c`. I need to understand the tunneling aspects of this. That will likely lead me to `udp_tunnel_xmit_skb`. I'm expecting to find the key logic there around packet construction and segmentation. I need to see how these functions coordinate to handle fragmentation in the context of tunnels. I need to understand the interaction between the UFO, GSO, and any tunnel specific optimizations. I'm looking for any hints about potential packet size limitations or how the system handles the complexities of nested headers.
62/2	2026/07/07 03:00	tool	grepper	0m Args: { "Expression": "udp_tunnel_xmit_skb", "PathPrefix": "net/ipv4/udp_tunnel_core.c" } Results: { "Output": "net/ipv4/udp_tunnel_core.c=166=EXPORT_SYMBOL_GPL(udp_tunnel_notify_del_rx_port);\nnet/ipv4/udp_tunnel_core.c-167-\nnet/ipv4/udp_tunnel_core.c:168:void udp_tunnel_xmit_skb(struct rtable rt, struct sock sk, struct sk_buff *skb,\nnet/ipv4/udp_tunnel_core.c-169-\t\t\t __be32 src, __be32 dst, __u8 tos, __u8 ttl,\n--\nnet/ipv4/udp_tunnel_core.c-189-}\nnet/ipv4/udp_tunnel_core.c:190:EXPORT_SYMBOL_GPL(udp_tunnel_xmit_skb);\nnet/ipv4/udp_tunnel_core.c-191-\n" }
63/2	2026/07/07 03:00	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 42105 output: 43 thoughts: 49 Thoughts: Okay, here's my take on those thoughts, framed as my own mental process, given my expertise: Examining Potential Tunneling Transmission Candidates Alright, looking at potential candidates for this transmission task, `udp_tunnel_xmit_skb` definitely piques my interest. It's a solid contender given the naming convention and likely function. Now, let's drill down and see if my suspicion holds. The next logical step is to dive into the IPv6 UDP tunneling code. I'll check `net/ipv6/ip6_udp_tunnel.c`. Specifically, I'm going to examine the function `udp_tunnel6_xmit_skb`. This seems like a strong bet, given that we're dealing with UDP tunneling and IPv6. It's likely involved in transmitting the SKB. Let's see what the implementation looks like and how it handles the details. It probably handles the encapsulation and header construction. I suspect there will be checks for tunnel parameters and some clever optimizations.
64/2	2026/07/07 03:00	tool	grepper	0m Args: { "Expression": "udp_tunnel6_xmit_skb", "PathPrefix": "net/ipv6/ip6_udp_tunnel.c" } Results: { "Output": "net/ipv6/ip6_udp_tunnel.c=75=EXPORT_SYMBOL_GPL(udp_sock_create6);\nnet/ipv6/ip6_udp_tunnel.c-76-\nnet/ipv6/ip6_udp_tunnel.c:77:void udp_tunnel6_xmit_skb(struct dst_entry dst, struct sock sk,\nnet/ipv6/ip6_udp_tunnel.c-78-\t\t\t struct sk_buff *skb,\n--\nnet/ipv6/ip6_udp_tunnel.c-113-}\nnet/ipv6/ip6_udp_tunnel.c:114:EXPORT_SYMBOL_GPL(udp_tunnel6_xmit_skb);\nnet/ipv6/ip6_udp_tunnel.c-115-\n" }
65/2	2026/07/07 03:00	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 42623 output: 40 thoughts: 47 Thoughts: Okay, here's my take on those thoughts, framed as my own reasoning: Candidate Identified: UDP Tunnel Offload Alright, based on what I'm looking at, `udp_tunnel6_xmit_skb` seems like a strong contender for the area I need to investigate further. It's a key function in handling these packets, I need to understand its role. I need to understand this part of the flow. Now, let's dive into the code itself. I'll need to locate the implementation, which likely lives under `net/ipv4/`. I'm going to want to focus on offload capabilities, so let's check `udp_offload.c` directly. My suspicion is that this is the correct place to begin the analysis. And yes, here it is, `__skb_udp_tunnel_segment`. Bingo! This looks like the core function involved in breaking down the SKB for tunneling. This is exactly what I was hoping to find, the segmentation logic is in this area, that's what I needed. Now, I can really start to get into the details of the tunneling implementation.
66/2	2026/07/07 03:00	tool	grepper	0m Args: { "Expression": "__skb_udp_tunnel_segment", "PathPrefix": "net/ipv4/udp_offload.c" } Results: { "Output": "net/ipv4/udp_offload.c=163=static struct sk_buff udp_tunnel_gro_rcv(struct sock sk,\n--\nnet/ipv4/udp_offload.c-171-\nnet/ipv4/udp_offload.c:172:static struct sk_buff __skb_udp_tunnel_segment(struct sk_buff skb,\nnet/ipv4/udp_offload.c-173-\tnetdev_features_t features,\n--\nnet/ipv4/udp_offload.c=309=struct sk_buff skb_udp_tunnel_segment(struct sk_buff skb,\n--\nnet/ipv4/udp_offload.c-337-\nnet/ipv4/udp_offload.c:338:\tsegs = __skb_udp_tunnel_segment(skb, features, gso_inner_segment,\nnet/ipv4/udp_offload.c-339-\t\t\t\t\tprotocol, is_ipv6);\n" }
67/2	2026/07/07 03:00	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 43219 output: 36 thoughts: 42 Thoughts: Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise: Examining UDP Offload Possibilities Alright, based on the context, I think `__skb_udp_tunnel_segment` looks like a promising function to investigate further. It's often involved in handling UDP traffic, especially in tunneling scenarios, which is precisely what I'm looking at. Let's delve into the actual implementation. I'll head over to `net/ipv4/udp_offload.c` and take a closer look at the source code there. I suspect the function `udp_gro_complete` is going to be relevant as well. We'll examine that and its interactions as well.
68/2	2026/07/07 03:01	tool	grepper	0m Args: { "Expression": "udp_gro_complete", "PathPrefix": "net/ipv4/udp_offload.c" } Results: { "Output": "net/ipv4/udp_offload.c=868=struct sk_buff udp4_gro_receive(struct list_head head, struct sk_buff skb)\n--\nnet/ipv4/udp_offload.c-898-\nnet/ipv4/udp_offload.c:899:static int udp_gro_complete_segment(struct sk_buff skb)\nnet/ipv4/udp_offload.c-900-{\n--\nnet/ipv4/udp_offload.c-915-\nnet/ipv4/udp_offload.c:916:int udp_gro_complete(struct sk_buff skb, int nhoff,\nnet/ipv4/udp_offload.c-917-\t\t udp_lookup_t lookup)\n--\nnet/ipv4/udp_offload.c-943-\t} else {\nnet/ipv4/udp_offload.c:944:\t\terr = udp_gro_complete_segment(skb);\nnet/ipv4/udp_offload.c-945-\t}\n--\nnet/ipv4/udp_offload.c=953=INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff skb, int nhoff)\n--\nnet/ipv4/udp_offload.c-974-\nnet/ipv4/udp_offload.c:975:\treturn udp_gro_complete(skb, nhoff, udp4_lib_lookup_skb);\nnet/ipv4/udp_offload.c-976-}\n" }
69/2	2026/07/07 03:01	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 43858 output: 37 thoughts: 39 Thoughts: Okay, here's my take on those thoughts, framed as my own: Considering UDP GRO Completion Right, let's zero in on this GRO completion process for UDP. `udp_gro_complete` seems like a prime spot to start digging. It just feels right. Time to dive into the codebase. I need to get a clear picture of how this is actually implemented. Let me take a look at the code in `net/ipv6/udp_offload.c`, and more specifically, `udp6_gro_complete`. That should give me the lowdown on the IPv6 implementation, which usually provides a solid foundation for understanding the broader UDP GRO handling. With my experience, I think this should be a productive avenue.
70/2	2026/07/07 03:02	tool	grepper	0m Args: { "Expression": "udp6_gro_complete", "PathPrefix": "net/ipv6/udp_offload.c" } Results: { "Output": "net/ipv6/udp_offload.c=134=struct sk_buff udp6_gro_receive(struct list_head head, struct sk_buff skb)\n--\nnet/ipv6/udp_offload.c-165-\nnet/ipv6/udp_offload.c:166:int udp6_gro_complete(struct sk_buff skb, int nhoff)\nnet/ipv6/udp_offload.c-167-{\n--\nnet/ipv6/udp_offload.c=191=int __init udpv6_offload_init(void)\n--\nnet/ipv6/udp_offload.c-196-\t\t\t.gro_receive\t=\tudp6_gro_receive,\nnet/ipv6/udp_offload.c:197:\t\t\t.gro_complete\t=\tudp6_gro_complete,\nnet/ipv6/udp_offload.c-198-\t\t},\n" }
71/2	2026/07/07 03:02	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 44340 output: 32 thoughts: 35 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Considering Potential GRO Completion Candidates Alright, let's zero in. Thinking about completing GRO (Generic Receive Offload), and my instincts are pointing towards `udp6_gro_complete`. It feels right, but I need to confirm. My immediate next step is to examine the source. Let's delve into `net/core/skbuff.c`. I'm especially interested in understanding how the segmentation and reassembly process is handled at a low level. More specifically, I should be looking at `skb_segment` within that file, as it’s critical for understanding how packets are broken down and put back together. This function will be key to understanding the context of my candidate for GRO completion.
72/2	2026/07/07 03:03	tool	grepper	0m Args: { "Expression": "skb_segment", "PathPrefix": "net/core/skbuff.c" } Results: { "Output": "net/core/skbuff.c=4656=static inline skb_frag_t skb_head_frag_to_page_desc(struct sk_buff frag_skb)\n--\nnet/core/skbuff.c-4667-\nnet/core/skbuff.c:4668:struct sk_buff skb_segment_list(struct sk_buff skb,\nnet/core/skbuff.c-4669-\t\t\t\t netdev_features_t features,\n--\nnet/core/skbuff.c-4759-}\nnet/core/skbuff.c:4760:EXPORT_SYMBOL_GPL(skb_segment_list);\nnet/core/skbuff.c-4761-\nnet/core/skbuff.c-4762-/\nnet/core/skbuff.c:4763: \tskb_segment - Perform protocol segmentation on skb.\nnet/core/skbuff.c-4764- \t@head_skb: buffer to segment\n--\nnet/core/skbuff.c-4770- /\nnet/core/skbuff.c:4771:struct sk_buff skb_segment(struct sk_buff head_skb,\nnet/core/skbuff.c-4772-\t\t\t netdev_features_t features)\n--\nnet/core/skbuff.c-5027-\t\t\t\tnet_warn_ratelimited(\nnet/core/skbuff.c:5028:\t\t\t\t\t\"skb_segment: too many frags: %u %u\\n\",\nnet/core/skbuff.c-5029-\t\t\t\t\tpos, mss);\n--\nnet/core/skbuff.c-5123-}\nnet/core/skbuff.c:5124:EXPORT_SYMBOL_GPL(skb_segment);\nnet/core/skbuff.c-5125-\n" }
73/2	2026/07/07 03:03	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 45057 output: 34 thoughts: 105 Thoughts: Considering SKB Segmentation for Optimization Okay, so I'm evaluating where to optimize, and `skb_segment` is looking like a promising starting point. I need to dive deeper into the code to really understand the impact. First, let's take a look at `net/ipv4/udp.c`. I see modifications have been made to both `udp_rcv` and `udpv6_rcv`, and also to `udp_send_skb` and `udp_v6_send_skb`. Hmm, these are definitely hot paths – the core of UDP reception and transmission. Given the potential for performance regression, I need to be very careful if I make modifications here. I think I'll aim to avoid touching those functions if possible. Now, let's switch gears and investigate `net/core/tso.c`. I'm curious about the specific use of `tso_build_hdr`. Understanding this part is crucial.
74/2	2026/07/07 03:03	tool	grepper	0m Args: { "Expression": "tso_build_hdr", "PathPrefix": "net/core/tso.c" } Results: { "Output": "net/core/tso.c-8-\nnet/core/tso.c:9:void tso_build_hdr(const struct sk_buff skb, char hdr, struct tso_t *tso,\nnet/core/tso.c-10-\t\t int size, bool is_last)\n--\nnet/core/tso.c-45-}\nnet/core/tso.c:46:EXPORT_SYMBOL(tso_build_hdr);\nnet/core/tso.c-47-\n" }
75/2	2026/07/07 03:03	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 45547 output: 32 thoughts: 35 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Considering Potential Candidates Alright, based on the context I'm processing, `tso_build_hdr` is looking like a solid lead. My initial instinct is that it's likely involved in the construction of headers, and that's precisely where I need to focus. To confirm and delve deeper, the next logical step is to examine the `drivers/net/geneve.c` file. Geneve, as an encapsulation protocol, is a likely place where header construction and manipulation would occur. Specifically, I'll pay close attention to the `geneve_setup` function within that file. This function name strongly implies it has something to do with initializing or configuring the Geneve protocol, which likely involves setting up or modifying header information. I'll need to see how it interacts with the underlying datapath and whether it directly calls into a function like `tso_build_hdr`. Let's see if this lines up.
76/2	2026/07/07 03:04	tool	grepper	0m Args: { "Expression": "geneve_setup", "PathPrefix": "drivers/net/geneve.c" } Results: { "Output": "drivers/net/geneve.c=1693=static void geneve_offload_rx_ports(struct net_device dev, bool push)\n--\ndrivers/net/geneve.c-1712-/ Initialize the device structure. /\ndrivers/net/geneve.c:1713:static void geneve_setup(struct net_device dev)\ndrivers/net/geneve.c-1714-{\n--\ndrivers/net/geneve.c=2531=static struct rtnl_link_ops geneve_link_ops __read_mostly = {\n--\ndrivers/net/geneve.c-2535-\t.priv_size\t= sizeof(struct geneve_dev),\ndrivers/net/geneve.c:2536:\t.setup\t\t= geneve_setup,\ndrivers/net/geneve.c-2537-\t.validate\t= geneve_validate,\n" }
77/2	2026/07/07 03:04	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 46068 output: 37 thoughts: 46 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Initial Assessment of Function and Code Location Right, so `geneve_setup` isn't a data path function, it's pretty clear it's just involved with the initial setup or configuration, which I kind of figured, but it's good to confirm. It won't be involved in the actual forwarding of data. Given that, I need to look for where the actual VXLAN data path logic resides. My gut feeling tells me the `drivers/net` directory is a likely candidate, and more specifically I'm betting it's in a file named something like `vxlan_core.c`. Let's confirm that hypothesis, so I'll be looking into `drivers/net/vxlan/vxlan_core.c`. Okay, the most obvious function name to look at is `vxlan_setup`, which is probably the critical entry point to examine within that file for the relevant data path operations. Let's see what that function does.
78/2	2026/07/07 03:04	tool	grepper	0m Args: { "Expression": "vxlan_setup", "PathPrefix": "drivers/net/vxlan/vxlan_core.c" } Results: { "Output": "drivers/net/vxlan/vxlan_core.c=3319=static void vxlan_offload_rx_ports(struct net_device dev, bool push)\n--\ndrivers/net/vxlan/vxlan_core.c-3345-/ Initialize the device structure. /\ndrivers/net/vxlan/vxlan_core.c:3346:static void vxlan_setup(struct net_device dev)\ndrivers/net/vxlan/vxlan_core.c-3347-{\n--\ndrivers/net/vxlan/vxlan_core.c=4678=static struct rtnl_link_ops vxlan_link_ops __read_mostly = {\n--\ndrivers/net/vxlan/vxlan_core.c-4682-\t.priv_size\t= sizeof(struct vxlan_dev),\ndrivers/net/vxlan/vxlan_core.c:4683:\t.setup\t\t= vxlan_setup,\ndrivers/net/vxlan/vxlan_core.c-4684-\t.validate\t= vxlan_validate,\n" }
79/2	2026/07/07 03:04	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 46651 output: 40 thoughts: 43 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Analyzing VXLAN Setup in Routing Context Right, `vxlan_setup` immediately doesn't seem like it's a core data path function. That suggests it's likely involved in control plane configuration or perhaps ancillary tasks rather than the actual forwarding of VXLAN packets themselves. I need to dig into the routing context to understand this better. My next move is to check `net/ipv4/route.c`. The intention is to determine how the route resolution and packet crafting are handled within the IPv4 routing subsystem. Specifically, I'm going to examine `inet_rtm_getroute_build_skb`, as that's the likely location for how the system handles the routing decisions and packet creation for outbound traffic. I want to see how VXLAN is integrated, if at all, at that stage.
80/2	2026/07/07 03:04	tool	grepper	0m Args: { "Expression": "inet_rtm_getroute_build_skb", "PathPrefix": "net/ipv4/route.c" } Results: { "Output": "net/ipv4/route.c=3127=int fib_dump_info_fnhe(struct sk_buff skb, struct netlink_callback cb,\n--\nnet/ipv4/route.c-3156-\nnet/ipv4/route.c:3157:static struct sk_buff inet_rtm_getroute_build_skb(__be32 src, __be32 dst,\nnet/ipv4/route.c-3158-\t\t\t\t\t\t u8 ip_proto, __be16 sport,\n--\nnet/ipv4/route.c=3287=static int inet_rtm_getroute(struct sk_buff in_skb, struct nlmsghdr *nlh,\n--\nnet/ipv4/route.c-3335-\nnet/ipv4/route.c:3336:\tskb = inet_rtm_getroute_build_skb(src, dst, ip_proto, sport, dport);\nnet/ipv4/route.c-3337-\tif (!skb)\n" }
81/2	2026/07/07 03:04	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 47196 output: 37 thoughts: 55 Thoughts: Here's my take on the thought process, as if it were my own: Investigating Network Route Table Modification Okay, so I need to figure out a good starting point for examining this network route table modification. My initial instinct is that `inet_rtm_getroute_build_skb` looks like a promising function to dig into. That feels like a logical candidate, given its name. Now, let's see... where's the most likely place to find related code? I'll check `net/ipv4/ipconfig.c`. That file usually holds the IP configuration and possibly the route-related interactions I'm after. Hmm... after a quick scan of `ipconfig.c` I see `ic_bootp_send_if` and `ic_bootp_recv`. Might be helpful if those are used to set the initial routes. Let me keep those in mind as I search.
82/2	2026/07/07 03:04	tool	grepper	0m Args: { "Expression": "ic_bootp_send_if", "PathPrefix": "net/ipv4/ipconfig.c" } Results: { "Output": "net/ipv4/ipconfig.c=809=static inline void __init ic_bootp_cleanup(void)\n--\nnet/ipv4/ipconfig.c-817- /\nnet/ipv4/ipconfig.c:818:static void __init ic_bootp_send_if(struct ic_device d, unsigned long jiffies_diff)\nnet/ipv4/ipconfig.c-819-{\n--\nnet/ipv4/ipconfig.c=1187=static int __init ic_dynamic(void)\n--\nnet/ipv4/ipconfig.c-1251-\t\tif (do_bootp \u0026\u0026 (d-\u003eable \u0026 IC_BOOTP))\nnet/ipv4/ipconfig.c:1252:\t\t\tic_bootp_send_if(d, jiffies - start_jiffies);\nnet/ipv4/ipconfig.c-1253-#endif\n" }
83/2	2026/07/07 03:04	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 47723 output: 34 thoughts: 65 Thoughts: Here's my summary, as though I'm thinking through this process: Fuzzing BOOTP: Initial Assessment Okay, so I'm looking at this code with the goal of fuzzing the BOOTP implementation. Right off the bat, `ic_bootp_send_if` and `ic_bootp_recv` are flagged as `__init` functions. That's not ideal. `__init` means they're likely only called during the initial system setup or module loading, making them less interesting targets for ongoing, runtime fuzzing. I need to find something that's active throughout the network stack's operation. Let's pivot. Since BOOTP is about building packets, I'll shift focus to how these packets are constructed at a lower level. My hunch is that I'll find potential fuzzing candidates in the packet generation routines. I'm going to check out `net/core/pktgen.c` now. Hopefully I can find some candidate functions there, and specifically I'm going to examine `fill_packet_ipv4` and `fill_packet_ipv6`. Those are the prime candidates.
84/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "fill_packet_ipv4", "PathPrefix": "net/core/pktgen.c" } Results: { "Output": "net/core/pktgen.c=2900=static struct sk_buff pktgen_alloc_skb(struct net_device dev,\n--\nnet/core/pktgen.c-2926-\nnet/core/pktgen.c:2927:static struct sk_buff fill_packet_ipv4(struct net_device odev,\nnet/core/pktgen.c-2928-\t\t\t\t\tstruct pktgen_dev pkt_dev)\n--\nnet/core/pktgen.c=3185=static struct sk_buff fill_packet(struct net_device *odev,\n--\nnet/core/pktgen.c-3190-\telse\nnet/core/pktgen.c:3191:\t\treturn fill_packet_ipv4(odev, pkt_dev);\nnet/core/pktgen.c-3192-}\n" }
85/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48295 output: 32 thoughts: 58 Thoughts: Here's my summary, as though I'm thinking through this process: Network Packet Construction Candidates Okay, so I'm looking at packet construction methods, and right off the bat, `fill_packet_ipv4` and `fill_packet_ipv6` seem like solid starting points. They are pretty generic, so they are a common point for building on and can be relevant across a few different scenarios, so it's worth checking them out. Now, let's pivot and see what we have in `drivers/net/amt.c`. I have a feeling the AMT (Automatic Multicast Tunneling) code might offer some useful building blocks or, at the very least, insight into how they've handled similar packet construction or modification tasks within the kernel. Let's see... looking at the function names: `amt_send_discovery`, `amt_send_request`, and `amt_send_advertisement`. Those all sound like they're directly related to specific packet types, so they are likely to contain examples of constructing and populating fields. I'll need to check the implementations to determine their suitability, but I'm thinking these functions will offer something useful for the task at hand.
86/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "amt_send_discovery", "PathPrefix": "drivers/net/amt.c" } Results: { "Output": "drivers/net/amt.c=605=static void amt_update_relay_status(struct amt_tunnel_list tunnel,\n--\ndrivers/net/amt.c-612-\ndrivers/net/amt.c:613:static void amt_send_discovery(struct amt_dev amt)\ndrivers/net/amt.c-614-{\n--\ndrivers/net/amt.c=932=static void amt_event_send_discovery(struct amt_dev *amt)\n--\ndrivers/net/amt.c-937-\ndrivers/net/amt.c:938:\tamt_send_discovery(amt);\ndrivers/net/amt.c-939-out:\n" }
87/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48826 output: 31 thoughts: 47 Thoughts: Okay, here's my take on those initial thoughts, expressed from a first-person perspective, assuming I'm already deep in the weeds of network driver investigation: My Initial Assessment Alright, given the context, I think we're on the right track with `amt_send_discovery`, `amt_send_request`, and `amt_send_advertisement`. They're the obvious starting points when considering the network protocols involved in this problem, likely related to Automated Management Tunneling (AMT). But, before I get too far down that path, let's just make sure, let's not assume, there might be a more likely candidate based on context. Let me take a look at `drivers/net/netconsole.c`. It's a low-level network console driver, and the name "netconsole" itself suggests this could very well be a relevant place. It would make sense if we're dealing with something related to debug or management interfaces. Ah yes, and I see `push_udp` in there, which likely makes it an excellent fit for AMT functions or any other similar UDP-based network functions.
88/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "push_udp", "PathPrefix": "drivers/net/netconsole.c" } Results: { "Output": "drivers/net/netconsole.c=1757=static void netpoll_udp_checksum(struct netpoll np, struct sk_buff skb,\n--\ndrivers/net/netconsole.c-1781-\ndrivers/net/netconsole.c:1782:static void push_udp(struct netpoll np, struct sk_buff skb, int len)\ndrivers/net/netconsole.c-1783-{\n--\ndrivers/net/netconsole.c=1864=static int netpoll_send_udp(struct netpoll np, const char msg, int len)\n--\ndrivers/net/netconsole.c-1887-\ndrivers/net/netconsole.c:1888:\tpush_udp(np, skb, len);\ndrivers/net/netconsole.c-1889-\tif (np-\u003eipv6)\n" }
89/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 49372 output: 42 thoughts: 42 Thoughts: Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise: Examining the UDP Traffic Flow Right, `push_udp` is a solid starting point for investigating this. Seems like a natural candidate for the part of the code I need to scrutinize. Now, let's dive into the kernel source, specifically the network device simulation driver. I'll go straight to `drivers/net/netdevsim/dev.c`. I need to understand how the simulated network devices interact and handle packets. My hunch is that this is where I'll find the relevant packet manipulation, or perhaps the point where a simulation artifact is occurring. Let me look at the `nsim_dev_trap_skb_build` function. I have to see how it constructs the simulated SKBs for traffic. It is likely the place where the UDP packet is being manipulated.
90/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "nsim_dev_trap_skb_build", "PathPrefix": "drivers/net/netdevsim/dev.c" } Results: { "Output": "drivers/net/netdevsim/dev.c=790=static const struct devlink_trap nsim_traps_arr[] = {\n--\ndrivers/net/netdevsim/dev.c-810-\ndrivers/net/netdevsim/dev.c:811:static struct sk_buff nsim_dev_trap_skb_build(void)\ndrivers/net/netdevsim/dev.c-812-{\n--\ndrivers/net/netdevsim/dev.c=853=static void nsim_dev_trap_report(struct nsim_dev_port nsim_dev_port)\n--\ndrivers/net/netdevsim/dev.c-875-\ndrivers/net/netdevsim/dev.c:876:\t\tskb = nsim_dev_trap_skb_build();\ndrivers/net/netdevsim/dev.c-877-\t\tif (!skb)\n" }
91/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 49886 output: 44 thoughts: 52 Thoughts: Okay, here's my interpretation of those thoughts, crafted with the understanding that I'm discussing this with a fellow expert: Investigating SKB Construction within the Netdevsim Driver Alright, I'm thinking that `nsim_dev_trap_skb_build` is a solid starting point for our investigation. It seems like it's a prime candidate for the SKB construction logic we're interested in. Given its name, it probably is responsible for how the SKB is built within the context of packet trapping or interception. Let's drill down and confirm that suspicion by inspecting `drivers/net/netdevsim/psample.c`. I'm going to look specifically at how it constructs the SKB. Specifically, I'll be looking for `nsim_dev_psample_skb_build`. This looks like a promising function to examine, as it strongly suggests packet sampling within Netdevsim. Understanding how this particular function builds the SKB could illuminate the broader picture and reveal critical details about the process, which is important.
92/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "nsim_dev_psample_skb_build", "PathPrefix": "drivers/net/netdevsim/psample.c" } Results: { "Output": "drivers/net/netdevsim/psample.c=23=struct nsim_dev_psample {\n--\ndrivers/net/netdevsim/psample.c-37-\ndrivers/net/netdevsim/psample.c:38:static struct sk_buff nsim_dev_psample_skb_build(void)\ndrivers/net/netdevsim/psample.c-39-{\n--\ndrivers/net/netdevsim/psample.c=111=static void nsim_dev_psample_report_work(struct work_struct work)\n--\ndrivers/net/netdevsim/psample.c-119-\ndrivers/net/netdevsim/psample.c:120:\tskb = nsim_dev_psample_skb_build();\ndrivers/net/netdevsim/psample.c-121-\tif (!skb)\n" }
93/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 50439 output: 37 thoughts: 46 Thoughts: Okay, here's my interpretation of those thoughts, crafted with the perspective of someone knowledgeable in network simulation and kernel code: Thinking Through a Network Packet Simulation Module Alright, based on the function name, `nsim_dev_psample_skb_build` looks like a strong starting point. It suggests that this is where the packet sampling and SKB (Socket Buffer) construction for the network simulation device is likely handled. Good candidate for inspection. Now, where's the actual implementation? The logical place to start is the `drivers/net/netdevsim/` directory, especially the `psp.c` file which likely pertains to packet sampling or processing. Let's dig into that file. Specifically, I should be looking at the `nsim_do_psp` function. That name sounds like the core of the packet sampling/processing logic. I'm guessing that's where the heart of this functionality resides and where I will want to focus my attention. It could be the gateway to understanding how simulated packets are generated and handled within this network simulation environment.
94/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "nsim_do_psp", "PathPrefix": "drivers/net/netdevsim/psp.c" } Results: { "Output": "drivers/net/netdevsim/psp.c=17=enum skb_drop_reason\ndrivers/net/netdevsim/psp.c:18:nsim_do_psp(struct sk_buff skb, struct netdevsim ns,\ndrivers/net/netdevsim/psp.c-19-\t struct netdevsim peer_ns, struct skb_ext *psp_ext)\n" }
95/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 50859 output: 34 thoughts: 37 Thoughts: Okay, here's my take on those thoughts, framed as my own mental process: Initial Assessment of Candidate Functions Hmm, `nsim_do_psp`... yeah, that one's definitely a strong contender, right off the bat. It just feels right for the task at hand. Let's see... gotta be sure before committing, of course. Okay, time to dive into the codebase. I need to investigate `net/psp/psp_main.c` . It's a key part of this PSP module, so that should provide a good overview of what's going on. I'm especially interested in understanding header writing and modification behavior. Right, let's look for `psp_write_headers`. This is a classic header operation. Should tell me everything I need to know about where and how this module does its things.
96/2	2026/07/07 03:05	tool	grepper	0m Args: { "Expression": "psp_write_headers", "PathPrefix": "net/psp/psp_main.c" } Results: { "Output": "net/psp/psp_main.c=186=EXPORT_SYMBOL(psp_key_size);\nnet/psp/psp_main.c-187-\nnet/psp/psp_main.c:188:static void psp_write_headers(struct net net, struct sk_buff skb, __be32 spi,\nnet/psp/psp_main.c-189-\t\t\t u8 ver, unsigned int udp_len, __be16 sport)\n--\nnet/psp/psp_main.c=248=bool psp_dev_encapsulate(struct net net, struct sk_buff skb, __be32 spi,\n--\nnet/psp/psp_main.c-282-\tskb-\u003eencapsulation = 1;\nnet/psp/psp_main.c:283:\tpsp_write_headers(net, skb, spi, ver,\nnet/psp/psp_main.c-284-\t\t\t skb-\u003elen - skb_transport_offset(skb), sport);\n" }
97/2	2026/07/07 03:05	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 51382 output: 40 thoughts: 42 Thoughts: Okay, here's my take on those thoughts, framed as my own reasoning: Initial Assessment and Exploration Hmm, based on this initial prompt, `psp_write_headers` seems like a strong contender as a starting point. That function name feels right, like it could potentially handle the specific kind of header manipulation I'm considering. However, I know better than to jump to conclusions. I've been down that road before and it's always better to cast a wider net at the beginning. Okay, let's explore a related area and check out what's happening with NAT (Network Address Translation). I think the `net/xfrm` subsystem is a reasonable place to start, given the likely context. Specifically, `xfrm_nat_keepalive.c` - that seems like a good target file since it's about NAT and keep-alives. Let me dig into that...Ah, here we go, `nat_keepalive_send`. That looks promising too. Let me see how things work there...
98/2	2026/07/07 03:06	tool	grepper	0m Args: { "Expression": "nat_keepalive_send", "PathPrefix": "net/xfrm/xfrm_nat_keepalive.c" } Results: { "Output": "net/xfrm/xfrm_nat_keepalive.c=31=static void nat_keepalive_init(struct nat_keepalive ka, struct xfrm_state x)\n--\nnet/xfrm/xfrm_nat_keepalive.c-41-\nnet/xfrm/xfrm_nat_keepalive.c:42:static int nat_keepalive_send_ipv4(struct sk_buff skb,\nnet/xfrm/xfrm_nat_keepalive.c-43-\t\t\t\t struct nat_keepalive ka)\n--\nnet/xfrm/xfrm_nat_keepalive.c-72-#if IS_ENABLED(CONFIG_IPV6)\nnet/xfrm/xfrm_nat_keepalive.c:73:static int nat_keepalive_send_ipv6(struct sk_buff skb,\nnet/xfrm/xfrm_nat_keepalive.c-74-\t\t\t\t struct nat_keepalive ka,\n--\nnet/xfrm/xfrm_nat_keepalive.c-114-\nnet/xfrm/xfrm_nat_keepalive.c:115:static void nat_keepalive_send(struct nat_keepalive ka)\nnet/xfrm/xfrm_nat_keepalive.c-116-{\n--\nnet/xfrm/xfrm_nat_keepalive.c-142-\tcase AF_INET:\nnet/xfrm/xfrm_nat_keepalive.c:143:\t\terr = nat_keepalive_send_ipv4(skb, ka);\nnet/xfrm/xfrm_nat_keepalive.c-144-\t\tbreak;\n--\nnet/xfrm/xfrm_nat_keepalive.c-146-\tcase AF_INET6:\nnet/xfrm/xfrm_nat_keepalive.c:147:\t\terr = nat_keepalive_send_ipv6(skb, ka, uh);\nnet/xfrm/xfrm_nat_keepalive.c-148-\t\tbreak;\n--\nnet/xfrm/xfrm_nat_keepalive.c=160=static int nat_keepalive_work_single(struct xfrm_state x, int count, void *ptr)\n--\nnet/xfrm/xfrm_nat_keepalive.c-189-\tif (send_keepalive)\nnet/xfrm/xfrm_nat_keepalive.c:190:\t\tnat_keepalive_send(\u0026ka);\nnet/xfrm/xfrm_nat_keepalive.c-191-\n" }
99/2	2026/07/07 03:06	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 52315 output: 40 thoughts: 56 Thoughts: Okay, here's my take on those thoughts, framed as my own: Investigating Potential TCP Keepalive Optimization Right, thinking about this... `nat_keepalive_send` seems like a pretty strong candidate to start with. It's the obvious starting point. I need to understand if the kernel currently does any checksumming in the keepalive path or any related path, so let's dig into that and see if it is necessary. Now, where was that checksumming logic? Ah, yes, I recall seeing some relevant code in `net/sched/act_csum.c`. I need to review this to see what checksum offload features it may support. Let's see... looking at that file, it looks like `tcf_csum_ipv4_udp` and `tcf_csum_ipv6_udp` might be relevant functions to investigate. I need to understand how these relate to the TCP keepalive process and if there's any intersection or opportunity for optimization there.
100/2	2026/07/07 03:06	tool	grepper	0m Args: { "Expression": "tcf_csum_ipv4_udp", "PathPrefix": "net/sched/act_csum.c" } Results: { "Output": "net/sched/act_csum.c=230=static int tcf_csum_ipv6_tcp(struct sk_buff skb, unsigned int ihl,\n--\nnet/sched/act_csum.c-254-\nnet/sched/act_csum.c:255:static int tcf_csum_ipv4_udp(struct sk_buff skb, unsigned int ihl,\nnet/sched/act_csum.c-256-\t\t\t unsigned int ipl, int udplite)\n--\nnet/sched/act_csum.c=389=static int tcf_csum_ipv4(struct sk_buff skb, u32 update_flags)\n--\nnet/sched/act_csum.c-421-\t\tif (update_flags \u0026 TCA_CSUM_UPDATE_FLAG_UDP)\nnet/sched/act_csum.c:422:\t\t\tif (!tcf_csum_ipv4_udp(skb, iph-\u003eihl 4,\nnet/sched/act_csum.c-423-\t\t\t\t\t ntohs(iph-\u003etot_len), 0))\n--\nnet/sched/act_csum.c-427-\t\tif (update_flags \u0026 TCA_CSUM_UPDATE_FLAG_UDPLITE)\nnet/sched/act_csum.c:428:\t\t\tif (!tcf_csum_ipv4_udp(skb, iph-\u003eihl * 4,\nnet/sched/act_csum.c-429-\t\t\t\t\t ntohs(iph-\u003etot_len), 1))\n" }
101/2	2026/07/07 03:06	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 53031 output: 41 thoughts: 60 Thoughts: Okay, here's my take on those initial thoughts, framed as a concise summary for an expert: Checksum Considerations for UDP in Netfilter Right, thinking about checksum handling for UDP packets, my initial gut feeling is that `tcf_csum_ipv4_udp` and `tcf_csum_ipv6_udp` are promising starting points. I'm going to quickly check `net/netfilter/nf_nat_helper.c` to see how NAT might be interacting with these. Specifically, I need to jog my memory about the `nf_nat_mangle_udp_packet` function and how it approaches this. That will probably be the key to understanding any existing checksum modifications.
102/2	2026/07/07 03:06	tool	grepper	0m Args: { "Expression": "nf_nat_mangle_udp_packet", "PathPrefix": "net/netfilter/nf_nat_helper.c" } Results: { "Output": "net/netfilter/nf_nat_helper.c=135=bool\nnet/netfilter/nf_nat_helper.c:136:nf_nat_mangle_udp_packet(struct sk_buff skb,\nnet/netfilter/nf_nat_helper.c-137-\t\t\t struct nf_conn ct,\n--\nnet/netfilter/nf_nat_helper.c-174-}\nnet/netfilter/nf_nat_helper.c:175:EXPORT_SYMBOL(nf_nat_mangle_udp_packet);\nnet/netfilter/nf_nat_helper.c-176-\n" }
103/2	2026/07/07 03:06	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 53446 output: 42 thoughts: 48 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Analyzing UDP Packet Manipulation Options Right, thinking about this... `nf_nat_mangle_udp_packet` seems like a solid starting point for examining how to tweak those UDP packets. It's often the go-to for NAT-related modifications, so it's probably where the action is happening. Let's dive into the kernel source and check out `net/netfilter/nf_log_syslog.c`. I recall that file having some relevant functions. Specifically, I'll need to check `nf_log_dump_udp_header`. That seems a likely candidate for inspecting and/or adapting the UDP header dumping code for our purposes.
104/2	2026/07/07 03:06	tool	grepper	0m Args: { "Expression": "nf_log_dump_udp_header", "PathPrefix": "net/netfilter/nf_log_syslog.c" } Results: { "Output": "net/netfilter/nf_log_syslog.c=276=static noinline_for_stack int\nnet/netfilter/nf_log_syslog.c:277:nf_log_dump_udp_header(struct nf_log_buf m,\nnet/netfilter/nf_log_syslog.c-278-\t\t const struct sk_buff skb,\n--\nnet/netfilter/nf_log_syslog.c=312=dump_ipv4_packet(struct net net, struct nf_log_buf m,\n--\nnet/netfilter/nf_log_syslog.c-383-\tcase IPPROTO_UDPLITE:\nnet/netfilter/nf_log_syslog.c:384:\t\tif (nf_log_dump_udp_header(m, skb, ih-\u003eprotocol,\nnet/netfilter/nf_log_syslog.c-385-\t\t\t\t\t ntohs(ih-\u003efrag_off) \u0026 IP_OFFSET,\n--\nnet/netfilter/nf_log_syslog.c=546=dump_ipv6_packet(struct net net, struct nf_log_buf m,\n--\nnet/netfilter/nf_log_syslog.c-711-\tcase IPPROTO_UDPLITE:\nnet/netfilter/nf_log_syslog.c:712:\t\tif (nf_log_dump_udp_header(m, skb, currenthdr, fragment, ptr))\nnet/netfilter/nf_log_syslog.c-713-\t\t\treturn;\n" }
105/2	2026/07/07 03:06	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 54090 output: 39 thoughts: 51 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Initial Assessment: UDP Logging & Error Handling Alright, `nf_log_dump_udp_header`... seems like a logging function, which is often more about debugging and post-mortem analysis than critical path performance. Unless something jumps out as profoundly problematic, I'm not going to immediately zero in on that. Let's dig deeper into the UDP connection tracking code itself. I'll need to examine `net/netfilter/nf_conntrack_proto_udp.c` now, specifically the `udp_error` function. That's probably where the meat of the error handling and state management for UDP connections resides. Knowing the error handling strategies will be paramount, and the logging will come in handy later.
106/2	2026/07/07 03:06	tool	grepper	0m Args: { "Expression": "udp_error", "PathPrefix": "net/netfilter/nf_conntrack_proto_udp.c" } Results: { "Output": "net/netfilter/nf_conntrack_proto_udp.c=32=static unsigned int udp_get_timeouts(struct net net)\n--\nnet/netfilter/nf_conntrack_proto_udp.c-36-\nnet/netfilter/nf_conntrack_proto_udp.c:37:static void udp_error_log(const struct sk_buff skb,\nnet/netfilter/nf_conntrack_proto_udp.c-38-\t\t\t const struct nf_hook_state state,\n--\nnet/netfilter/nf_conntrack_proto_udp.c=44=static bool udp_validate_len(struct sk_buff skb,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-55-\nnet/netfilter/nf_conntrack_proto_udp.c:56:static bool udp_error(struct sk_buff skb,\nnet/netfilter/nf_conntrack_proto_udp.c-57-\t\t unsigned int dataoff,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-65-\tif (!hdr) {\nnet/netfilter/nf_conntrack_proto_udp.c:66:\t\tudp_error_log(skb, state, \"short packet\");\nnet/netfilter/nf_conntrack_proto_udp.c-67-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c-71-\tif (!udp_validate_len(skb, hdr, dataoff)) {\nnet/netfilter/nf_conntrack_proto_udp.c:72:\t\tudp_error_log(skb, state, \"truncated/malformed packet\");\nnet/netfilter/nf_conntrack_proto_udp.c-73-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c-86-\t nf_checksum(skb, state-\u003ehook, dataoff, IPPROTO_UDP, state-\u003epf)) {\nnet/netfilter/nf_conntrack_proto_udp.c:87:\t\tudp_error_log(skb, state, \"bad checksum\");\nnet/netfilter/nf_conntrack_proto_udp.c-88-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c=95=int nf_conntrack_udp_packet(struct nf_conn *ct,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-103-\nnet/netfilter/nf_conntrack_proto_udp.c:104:\tif (udp_error(skb, dataoff, state))\nnet/netfilter/nf_conntrack_proto_udp.c-105-\t\treturn -NF_ACCEPT;\n" }
107/2	2026/07/07 03:06	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 55056 output: 44 thoughts: 48 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Initial Assessment and Targeted Investigation Alright, sounds like we've got a UDP-related error to troubleshoot. My gut feeling says `udp_error` is a solid starting point for investigation. It seems like it's the natural place to start looking at this kind of problem. Now, let's dive into some code. My instinct tells me to check the `net/ipv4/netfilter/nf_nat_snmp_basic_main.c` file. This looks like a likely area, as it deals with NAT and potentially SNMP, which could definitely be involved with UDP traffic. I need to refresh my memory on this section of code. I need to focus on a few key functions: `snmp_translate` and any help functions related to it. Those are the functions I'll need to focus on to get to the bottom of this. That's probably where the root of the error lies.
108/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "snmp_translate", "PathPrefix": "net/ipv4/netfilter/nf_nat_snmp_basic_main.c" } Results: { "Output": "net/ipv4/netfilter/nf_nat_snmp_basic_main.c=105=int snmp_helper(void context, size_t hdrlen, unsigned char tag,\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-125-\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c:126:static int snmp_translate(struct nf_conn ct, int dir, struct sk_buff skb)\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-127-{\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c=160=static int help(struct sk_buff skb, unsigned int protoff,\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-194-\tspin_lock_bh(\u0026snmp_lock);\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c:195:\tret = snmp_translate(ct, dir, skb);\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-196-\tspin_unlock_bh(\u0026snmp_lock);\n" }
109/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 55687 output: 36 thoughts: 37 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Investigating a Potential SNMP Translation Pathway Alright, let's see... the problem is about SNMP translation, so I'm immediately thinking `snmp_translate` – that seems like a strong initial candidate for where this functionality might reside. It's the logical place to start, given the nature of the problem. Now, where else might this be handled, especially if we're dealing with a constraint network, possibly even 6LoWPAN? Ah, yes, if this SNMP traffic needs to traverse a 6LoWPAN network the UDP part is important to figure out what happens in the transport layer, so let's dig into `net/6lowpan/nhc_udp.c`. That should give us a clearer view of what's happening. I should probably focus on `udp_uncompress`, see how this is translated.
110/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "udp_uncompress", "PathPrefix": "net/6lowpan/nhc_udp.c" } Results: { "Output": "net/6lowpan/nhc_udp.c-35-\nnet/6lowpan/nhc_udp.c:36:static int udp_uncompress(struct sk_buff *skb, size_t needed)\nnet/6lowpan/nhc_udp.c-37-{\n--\nnet/6lowpan/nhc_udp.c=171=LOWPAN_NHC(nhc_udp, \"RFC6282 UDP\", NEXTHDR_UDP, sizeof(struct udphdr),\nnet/6lowpan/nhc_udp.c:172:\t LOWPAN_NHC_UDP_ID, LOWPAN_NHC_UDP_MASK, udp_uncompress, udp_compress);\nnet/6lowpan/nhc_udp.c-173-\n" }
111/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 56161 output: 36 thoughts: 37 Thoughts: Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise: Potential Optimization: UDP Uncompression Right, thinking about this performance bottleneck, `udp_uncompress` seems like a likely area to investigate. It’s a classic, often-overlooked area for potential gains. I need to understand how efficiently it's handling the incoming data. Where would this logic likely reside? Aha! That's it, I need to check the WireGuard receive path. I'll need to dig into `drivers/net/wireguard/receive.c`. Let's see how they're handling packet reception and the decompressing, it all starts with the `prepare_skb_header` function... Let's see what's happening there.
112/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "prepare_skb_header", "PathPrefix": "drivers/net/wireguard/receive.c" } Results: { "Output": "drivers/net/wireguard/receive.c=28=static size_t validate_header_len(struct sk_buff skb)\n--\ndrivers/net/wireguard/receive.c-46-\ndrivers/net/wireguard/receive.c:47:static int prepare_skb_header(struct sk_buff skb, struct wg_device wg)\ndrivers/net/wireguard/receive.c-48-{\n--\ndrivers/net/wireguard/receive.c=542=void wg_packet_receive(struct wg_device wg, struct sk_buff *skb)\ndrivers/net/wireguard/receive.c-543-{\ndrivers/net/wireguard/receive.c:544:\tif (unlikely(prepare_skb_header(skb, wg) \u003c 0))\ndrivers/net/wireguard/receive.c-545-\t\tgoto err;\n" }
113/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 56633 output: 39 thoughts: 42 Thoughts: Okay, here's my take on those thoughts, framed as my own: Analyzing Potential Candidates for SKB Header Preparation Alright, looking at this problem, `prepare_skb_header` immediately jumps out as a strong contender. That's a logical starting point, considering the name. I'd expect it to be directly involved in the header construction phase. To be thorough, let's explore related areas. Let me go poke around in `drivers/infiniband/core/lag.c`. That's often a good spot for IB-specific network function interactions, and it might reveal how SKBs are handled in a low-level, high-performance context. Hmm, okay, after a quick scan of `lag.c`, let's see what `rdma_build_skb` might provide. Perhaps this will be a useful place to start debugging the SKB header construction process.
114/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "rdma_build_skb", "PathPrefix": "drivers/infiniband/core/lag.c" } Results: { "Output": "drivers/infiniband/core/lag.c-9-\ndrivers/infiniband/core/lag.c:10:static struct sk_buff rdma_build_skb(struct net_device netdev,\ndrivers/infiniband/core/lag.c-11-\t\t\t\t struct rdma_ah_attr ah_attr,\n--\ndrivers/infiniband/core/lag.c=80=static struct net_device rdma_get_xmit_slave_udp(struct ib_device *device,\n--\ndrivers/infiniband/core/lag.c-87-\ndrivers/infiniband/core/lag.c:88:\tskb = rdma_build_skb(master, ah_attr, flags);\ndrivers/infiniband/core/lag.c-89-\tif (!skb)\n" }
115/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 57130 output: 47 thoughts: 59 Thoughts: Here's my thought process, as if I were considering this issue: RDMA SKB Construction Investigation Okay, so I'm looking for the right approach here. My initial thought is that `rdma_build_skb` might be a really promising starting point, considering the context. Let's see if that's going to work. Now, where do I start digging? Given my familiarity with RDMA and networking, I'm immediately thinking the `drivers/infiniband/sw/rxe/rxe_net.c` file is the most likely place to find relevant code. Within that, I should focus on functions related to UDP encapsulation and receive paths. That likely means I want to examine `rxe_udp_encap_recv`, which is likely responsible for receiving the packets. I should also check out `prepare_udp_hdr` since that's probably handling the setup of the UDP header which is very relevant to my problem. Let's start there.
116/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "rxe_udp_encap_recv", "PathPrefix": "drivers/infiniband/sw/rxe/rxe_net.c" } Results: { "Output": "drivers/infiniband/sw/rxe/rxe_net.c=174=static struct dst_entry rxe_find_route(struct net_device ndev,\n--\ndrivers/infiniband/sw/rxe/rxe_net.c-218-\ndrivers/infiniband/sw/rxe/rxe_net.c:219:static int rxe_udp_encap_recv(struct sock sk, struct sk_buff skb)\ndrivers/infiniband/sw/rxe/rxe_net.c-220-{\n--\ndrivers/infiniband/sw/rxe/rxe_net.c=259=static struct socket rxe_setup_udp_tunnel(struct net net, __be16 port,\n--\ndrivers/infiniband/sw/rxe/rxe_net.c-282-\ttnl_cfg.encap_type = 1;\ndrivers/infiniband/sw/rxe/rxe_net.c:283:\ttnl_cfg.encap_rcv = rxe_udp_encap_recv;\ndrivers/infiniband/sw/rxe/rxe_net.c-284-\n" }
117/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 57765 output: 48 thoughts: 61 Thoughts: Here's my take on those code candidates: Thinking Through UDP Encapsulation Okay, so I'm thinking about where to start digging into this UDP encapsulation process. Based on my experience, `rxe_udp_encap_recv` and `prepare_udp_hdr` feel like solid starting points. They are likely involved directly in receiving and preparing the UDP headers, which is precisely what I'm interested in here. However, I'm going to shift gears and delve into `drivers/net/ethernet/sfc/tc_encap_actions.c`. Looking at that file should be interesting because I recall that specific driver dealing with traffic control and encapsulation actions. Specifically, I'm curious about how the `efx_gen_tun_header_udp` function handles UDP. I'd expect that function to be the one responsible for generating or manipulating the UDP headers in this setup, or at least involved in the overall control path. Let's see what secrets it holds.
118/2	2026/07/07 03:07	tool	grepper	0m Args: { "Expression": "efx_gen_tun_header_udp", "PathPrefix": "drivers/net/ethernet/sfc/tc_encap_actions.c" } Results: { "Output": "drivers/net/ethernet/sfc/tc_encap_actions.c=286=static void efx_gen_tun_header_ipv6(struct efx_tc_encap_action encap, u8 ipproto, u8 len)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-304-\ndrivers/net/ethernet/sfc/tc_encap_actions.c:305:static void efx_gen_tun_header_udp(struct efx_tc_encap_action encap, u8 len)\ndrivers/net/ethernet/sfc/tc_encap_actions.c-306-{\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=350=static void efx_gen_vxlan_header_ipv4(struct efx_tc_encap_action encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-354-\tefx_gen_tun_header_ipv4(encap, IPPROTO_UDP, vxlan_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:355:\tefx_gen_tun_header_udp(encap, sizeof(struct vxlanhdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-356-\tefx_gen_tun_header_vxlan(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=361=static void efx_gen_geneve_header_ipv4(struct efx_tc_encap_action encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-365-\tefx_gen_tun_header_ipv4(encap, IPPROTO_UDP, geneve_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:366:\tefx_gen_tun_header_udp(encap, sizeof(struct genevehdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-367-\tefx_gen_tun_header_geneve(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=372=static void efx_gen_vxlan_header_ipv6(struct efx_tc_encap_action encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-376-\tefx_gen_tun_header_ipv6(encap, IPPROTO_UDP, vxlan_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:377:\tefx_gen_tun_header_udp(encap, sizeof(struct vxlanhdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-378-\tefx_gen_tun_header_vxlan(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=382=static void efx_gen_geneve_header_ipv6(struct efx_tc_encap_action encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-386-\tefx_gen_tun_header_ipv6(encap, IPPROTO_UDP, geneve_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:387:\tefx_gen_tun_header_udp(encap, sizeof(struct genevehdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-388-\tefx_gen_tun_header_geneve(encap);\n" }
119/2	2026/07/07 03:07	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 59058 output: 50 thoughts: 57 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, as if they were my own: UDP Header Tuning Consideration Alright, looking at potential avenues for optimization, `efx_gen_tun_header_udp` definitely stands out as a strong candidate for further investigation. That function feels like a likely point where we can make some meaningful impact. Now, let's pivot to the Intel i40e driver. I need to take a look at the i40e code, specifically in `drivers/net/ethernet/intel/i40e/i40e_txrx.c`. I suspect there might be some interplay there. I'm also remembering `i40e_tso`, that could potentially be involved here as well. I'll need to drill down and see how that is managed in relation to UDP header generation.
120/2	2026/07/07 03:08	tool	grepper	0m Args: { "Expression": "i40e_tso", "PathPrefix": "drivers/net/ethernet/intel/i40e/i40e_txrx.c" } Results: { "Output": "drivers/net/ethernet/intel/i40e/i40e_txrx.c=3001=static inline int i40e_tx_prepare_vlan_flags(struct sk_buff skb,\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3067-/\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3068: i40e_tso - set up the tso context descriptor\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3069- * @first: pointer to first Tx buffer for xmit\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3074- */\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3075:static int i40e_tso(struct i40e_tx_buffer first, u8 hdr_len,\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3076-\t\t u64 cd_type_cmd_tso_mss)\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c=3868=static netdev_tx_t i40e_xmit_frame_ring(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3916-\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3917:\ttso = i40e_tso(first, \u0026hdr_len, \u0026cd_type_cmd_tso_mss);\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3918-\n" }
121/2	2026/07/07 03:08	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 59864 output: 44 thoughts: 48 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience: Considering TSO Implementation in Intel Network Drivers Alright, so I'm thinking about where to start looking at TSO implementation, and `i40e_tso` immediately jumps out as a strong possibility. It's a key driver, after all. Now, I want to drill down and see how it is actually handled. I'm going to quickly check `drivers/net/ethernet/intel/iavf/iavf_txrx.c` to see how the IAVF driver handles TSO, the related function `iavf_tso` is the exact function to examine, as I expect it to contain details on TSO-related processing.
122/2	2026/07/07 03:09	tool	grepper	0m Args: { "Expression": "iavf_tso", "PathPrefix": "drivers/net/ethernet/intel/iavf/iavf_txrx.c" } Results: { "Output": "drivers/net/ethernet/intel/iavf/iavf_txrx.c=1696=static void iavf_tx_prepare_vlan_flags(struct sk_buff skb,\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1721-/\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:1722: iavf_tso - set up the tso context descriptor\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1723- * @first: pointer to first Tx buffer for xmit\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1728- */\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:1729:static int iavf_tso(struct iavf_tx_buffer first, u8 hdr_len,\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1730-\t\t u64 cd_type_cmd_tso_mss)\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c=2291=static netdev_tx_t iavf_xmit_frame_ring(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-2352-\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:2353:\ttso = iavf_tso(first, \u0026hdr_len, \u0026cd_type_cmd_tso_mss);\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-2354-\n" }
123/2	2026/07/07 03:09	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 60570 output: 41 thoughts: 43 Thoughts: Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested: Assessing TSO Implementation Alright, looking at this networking code, `iavf_tso` is a likely contender for what I'm looking for. That seems to fit the bill based on what I know about this driver. Now, the next logical step is to dive into the implementation. I'll need to check the code that actually handles the Transmit Side Offload (TSO) functionality. Specifically, I'll navigate to `drivers/net/ethernet/intel/ice/ice_txrx.c` because that's where Intel drivers typically keep their core transmit and receive logic. Within that file, I'm betting that functions related to `ice_tso` will be the key. Let's start there. I'll get into the details of the actual function calls and data structures involved, but that's my initial hypothesis.
124/2	2026/07/07 03:09	tool	grepper	0m Args: { "Expression": "ice_tso", "PathPrefix": "drivers/net/ethernet/intel/ice/ice_txrx.c" } Results: { "Output": "drivers/net/ethernet/intel/ice/ice_txrx.c=1812=ice_tx_prepare_vlan_flags(struct ice_tx_ring tx_ring, struct ice_tx_buf first)\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1835-/*\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1836: ice_tso - computes mss and TSO length to prepare for TSO\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1837- * @first: pointer to struct ice_tx_buf\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c=1842=static\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1843:int ice_tso(struct ice_tx_buf first, struct ice_tx_offload_params off)\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1844-{\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c=2159=ice_xmit_frame_ring(struct sk_buff skb, struct ice_tx_ring tx_ring)\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-2213-\t/* set up TSO offload */\ndrivers/net/ethernet/intel/ice/ice_txrx.c:2214:\ttso = ice_tso(first, \u0026offload);\ndrivers/net/ethernet/intel/ice/ice_txrx.c-2215-\tif (tso \u003c 0)\n" }
125/2	2026/07/07 03:09	llm	patch-evaluator	1m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 61294 output: 44 thoughts: 45 Thoughts: Okay, here's my take on those thoughts, framed as my own mental process, given that I'm an expert: TSO Candidate Evaluation and Code Dive Right, let's see... `ice_tso`... yeah, that seems like a solid potential candidate for the TSO (TCP Segmentation Offload) implementation within the Intel network driver context. It's a plausible identifier for a TSO-specific function or module. Now, where to confirm? Given the context of Intel Ethernet drivers, the logical place to start digging is within the `drivers/net/ethernet/intel/idpf/` directory. And within that, let's target `idpf_txrx.c` which, with the `txrx` designation, seems likely to contain the transmit and receive path code. That file is probably where the TSO handling would be. Specifically, I'll be looking for `idpf_tso`. It's highly probable the function names will follow a consistent naming scheme. So, the likelihood of finding `idpf_tso` inside that file to confirm that hypothesis is high. Let's see if that's where we find the relevant TSO implementation details.
126/2	2026/07/07 03:11	tool	grepper	0m Args: { "Expression": "idpf_tso", "PathPrefix": "drivers/net/ethernet/intel/idpf/idpf_txrx.c" } Results: { "Output": "drivers/net/ethernet/intel/idpf/idpf_txrx.c=2642=static void idpf_tx_splitq_map(struct idpf_tx_queue tx_q,\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2813-/\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:2814: idpf_tso - computes mss and TSO length to prepare for TSO\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2815- * @skb: pointer to skb\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2820- /\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:2821:int idpf_tso(struct sk_buff skb, struct idpf_tx_offload_params off)\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2822-{\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c=3021=static netdev_tx_t idpf_tx_splitq_frame(struct sk_buff skb,\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-3036-\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:3037:\ttso = idpf_tso(skb, \u0026tx_params.offload);\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-3038-\tif (unlikely(tso \u003c 0))\n" }
127/2	2026/07/07 03:11	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 62086 output: 56 thoughts: 58 Thoughts: Okay, here's my interpretation of those thoughts, framed as my own: Initial Assessment of Candidate and Code Location Right, `idpf_tso`... that definitely seems like a strong contender for what I'm looking for. Let's make sure, I need to understand it better. My next step will be to dive into `drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c`. This is where I'd expect to find the lower-level details, especially anything related to transmission and reception, given the filename. And in particular I want to review `otx2_sqe_add_ext`. I'm hoping it'll shed light on the intricacies of how this TSO (or related) functionality is implemented.
128/2	2026/07/07 03:11	tool	grepper	0m Args: { "Expression": "otx2_sqe_add_ext", "PathPrefix": "drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c" } Results: { "Output": "drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c=662=static bool otx2_sqe_add_sg(struct otx2_nic pfvf, struct otx2_snd_queue sq,\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-706-/* Add SQE extended header subdescriptor /\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:707:static void otx2_sqe_add_ext(struct otx2_nic pfvf, struct otx2_snd_queue sq,\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-708-\t\t\t struct sk_buff skb, int offset)\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c=1189=bool otx2_sq_append_skb(void dev, struct netdev_queue txq,\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-1244-\t/ Add extended header if needed */\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:1245:\totx2_sqe_add_ext(pfvf, sq, skb, \u0026offset);\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-1246-\n" }
129/2	2026/07/07 03:11	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 62798 output: 56 thoughts: 81 Thoughts: Here's my analysis of those findings: Considering Packet Modification Points Okay, so I'm looking for the ideal spot to inject a modification. `otx2_sqe_add_ext` feels like a strong contender – it seems like the right level of abstraction to potentially intercept and manipulate packets before they're fully processed. I'll need to confirm that it's the right place, but my gut feeling is positive. Now, let's dive into the code. I'll navigate over to `drivers/net/ethernet/mellanox/mlx5/core/en_rx.c` specifically, the Mellanox Ethernet driver. Given the context, that's where I expect to find relevant RX path processing. Aha! It looks like `mlx5e_shampo_update_ipv4_udp_hdr` and `mlx5e_shampo_update_ipv6_udp_hdr` are prime targets! These functions specifically suggest they are involved in updating the headers of UDP packets, which is exactly where I'm aiming. They handle the IPv4 and IPv6 variants separately, meaning I need to make sure my logic covers both cases. My next step will be to thoroughly examine these functions to understand how and when the header updates happen, and identify the point at which to inject my changes.
130/2	2026/07/07 03:11	tool	grepper	0m Args: { "Expression": "mlx5e_shampo_update_ipv4_udp_hdr", "PathPrefix": "drivers/net/ethernet/mellanox/mlx5/core/en_rx.c" } Results: { "Output": "drivers/net/ethernet/mellanox/mlx5/core/en_rx.c=1021=static unsigned int mlx5e_lro_update_hdr(struct sk_buff skb,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1076-\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c:1077:static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq rq, struct iphdr ipv4)\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1078-{\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c=1207=static void mlx5e_shampo_update_hdr(struct mlx5e_rq rq, struct mlx5_cqe64 *cqe, bool match)\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1225-\t\telse\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c:1226:\t\t\tmlx5e_shampo_update_ipv4_udp_hdr(rq, ipv4);\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1227-\t} else {\n" }
131/2	2026/07/07 03:11	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 63587 output: 42 thoughts: 71 Thoughts: Here's my analysis of the situation: Potential Optimization Candidates Okay, so I'm thinking about where we might be able to make some headway here. Based on what I've seen, `mlx5e_shampo_update_ipv4_udp_hdr` and `mlx5e_shampo_update_ipv6_udp_hdr` seem like particularly promising areas to focus on. They deal with the header updates, which are often performance-sensitive spots. Now, I'm going to take a look into the `drivers/net/ethernet/sfc/falcon/selftest.c` file. I'm specifically interested in the `ef4_iterate_state` function within that file. I'll need to see if there's any relevant logic or potential insights that will provide some helpful insight into optimizing the headers.
132/2	2026/07/07 03:11	tool	grepper	0m Args: { "Expression": "ef4_iterate_state", "PathPrefix": "drivers/net/ethernet/sfc/falcon/selftest.c" } Results: { "Output": "drivers/net/ethernet/sfc/falcon/selftest.c=288=void ef4_loopback_rx_packet(struct ef4_nic efx,\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c-381-/ Initialise an ef4_selftest_state for a new iteration /\ndrivers/net/ethernet/sfc/falcon/selftest.c:382:static void ef4_iterate_state(struct ef4_nic efx)\ndrivers/net/ethernet/sfc/falcon/selftest.c-383-{\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c=537=ef4_test_loopback(struct ef4_tx_queue *tx_queue,\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c-557-\ndrivers/net/ethernet/sfc/falcon/selftest.c:558:\t\tef4_iterate_state(efx);\ndrivers/net/ethernet/sfc/falcon/selftest.c-559-\t\tbegin_rc = ef4_begin_loopback(tx_queue);\n" }
133/2	2026/07/07 03:11	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 64179 output: 55 thoughts: 64 Thoughts: Okay, let's get down to business. Here's how I'm approaching this: Initial Assessment and Targeted Investigation Alright, looking over this, I see `ef4_iterate_state` listed as a selftest function. I know that function, and in my experience, it's not the primary focus right now. It's safe to skip it for the purposes of a quick triage and not worth the time to investigate further, given the context. My attention is immediately drawn to the `drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c` file. The networking stack and STMicroelectronics' (ST) MAC driver are important in many systems I've worked on. I want to zero in on specific test cases, and the mention of `stmmac_test_get_udp_skb` is intriguing. That looks like a good place to start, as UDP testing can often reveal subtleties in driver and network stack interactions. I'll focus my efforts there to quickly understand potential testing methodologies and code behavior.
134/2	2026/07/07 03:12	tool	grepper	0m Args: { "Expression": "stmmac_test_get_udp_skb", "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c" } Results: { "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=57=static u8 stmmac_test_next_id;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-58-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:59:static struct sk_buff stmmac_test_get_udp_skb(struct stmmac_priv priv,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-60-\t\t\t\t\t struct stmmac_packet_attrs attr)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=320=static int __stmmac_test_loopback(struct stmmac_priv priv,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-342-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:343:\tskb = stmmac_test_get_udp_skb(priv, attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-344-\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=894=static int __stmmac_test_vlanfilt(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-932-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:933:\t\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-934-\t\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=987=static int __stmmac_test_dvlanfilt(struct stmmac_priv priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1026-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1027:\t\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1028-\t\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=1258=static int stmmac_test_vlanoff_common(struct stmmac_priv *priv, bool svlan)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1292-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1293:\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1294-\tif (!skb) {\n" }
135/2	2026/07/07 03:12	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 65399 output: 37 thoughts: 52 Thoughts: Here's my thought process, as requested: Assessing the Self-Test Landscape Alright, let's get down to business. I see `stmmac_test_get_udp_skb` listed in the tests. Hmm, that looks like a very specific, low-level function related to the stmmac driver. I'm going to skip that one for now; it's probably not where I want to focus my attention for a broader understanding. Instead, I'll shift gears. I'll need to look at more general networking functionality. My instincts tell me the place to start is likely in `net/core/selftests.c`. It's a standard location for core network self-tests. That makes sense. I need to get a high-level view of core net-tests. Okay, now let's see what's in there... Ah, there it is: `net_test_get_skb`. Let's focus on that one next.
136/2	2026/07/07 03:12	tool	grepper	0m Args: { "Expression": "net_test_get_skb", "PathPrefix": "net/core/selftests.c" } Results: { "Output": "net/core/selftests.c=17=static u8 net_test_next_id;\nnet/core/selftests.c-18-\nnet/core/selftests.c:19:struct sk_buff net_test_get_skb(struct net_device ndev, u8 id,\nnet/core/selftests.c-20-\t\t\t\t struct net_packet_attrs attr)\n--\nnet/core/selftests.c-156-}\nnet/core/selftests.c:157:EXPORT_SYMBOL_GPL(net_test_get_skb);\nnet/core/selftests.c-158-\n--\nnet/core/selftests.c=233=static int __net_test_loopback(struct net_device ndev,\n--\nnet/core/selftests.c-253-\nnet/core/selftests.c:254:\tskb = net_test_get_skb(ndev, net_test_next_id, attr);\nnet/core/selftests.c-255-\tif (!skb) {\n" }
137/2	2026/07/07 03:12	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 65997 output: 38 thoughts: 49 Thoughts: Okay, here's my summary, taking the perspective of someone familiar with kernel development and testing: Blackhole Device KUnit Test Exploration Right, so I'm scanning through the test suite and, frankly, `net_test_get_skb` doesn't really ring any bells, and it's probably a basic self-test, so I'm going to skip over that. Not really worth digging into. Let's move on to something more interesting. Okay, now this is more like it... `lib/tests/blackhole_dev_kunit.c`. That name sounds promising! I want to understand how the blackhole device is being tested. Time to check out the `test_blackholedev` function within that file. That's the specific test I'm going to focus on.
138/2	2026/07/07 03:12	tool	grepper	0m Args: { "Expression": "test_blackholedev", "PathPrefix": "lib/tests/blackhole_dev_kunit.c" } Results: { "Output": "lib/tests/blackhole_dev_kunit.c-26-\nlib/tests/blackhole_dev_kunit.c:27:static void test_blackholedev(struct kunit *test)\nlib/tests/blackhole_dev_kunit.c-28-{\n--\nlib/tests/blackhole_dev_kunit.c=71=static struct kunit_case blackholedev_cases[] = {\nlib/tests/blackhole_dev_kunit.c:72:\tKUNIT_CASE(test_blackholedev),\nlib/tests/blackhole_dev_kunit.c-73-\t{},\n" }
139/2	2026/07/07 03:12	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 66426 output: 34 thoughts: 82 Thoughts: Here's my thought process, as if I were reviewing this code: Quick Scan of Relevant Code Alright, I'm going through this code, and the first thing I see is a KUnit test, `test_blackholedev`. Not something I need to delve into for this particular review, so I'll skip over that one. Next, I'll take a look at `include/trace/events/icmp.h`. Aha, `TRACE_EVENT(icmp_send, ...)` indicates a tracepoint definition. I'm generally not interested in the tracepoints at this stage, so I'll bypass this as well. Now, let's move on to `net/ipv4/udp.c`. I'm curious about the UDP implementation, so I'll see what's in here. Okay, I see `udp_send_skb`. This looks like a function of interest. I will take note of that.
140/2	2026/07/07 03:12	tool	grepper	0m Args: { "Expression": "udp_send_skb", "PathPrefix": "net/ipv4/udp.c" } Results: { "Output": "net/ipv4/udp.c=1091=EXPORT_SYMBOL(udp_set_csum);\nnet/ipv4/udp.c-1092-\nnet/ipv4/udp.c:1093:static int udp_send_skb(struct sk_buff skb, struct flowi4 fl4,\nnet/ipv4/udp.c-1094-\t\t\tstruct inet_cork cork)\n--\nnet/ipv4/udp.c=1179=int udp_push_pending_frames(struct sock sk)\n--\nnet/ipv4/udp.c-1190-\nnet/ipv4/udp.c:1191:\terr = udp_send_skb(skb, fl4, \u0026inet-\u003ecork.base);\nnet/ipv4/udp.c-1192-\n--\nnet/ipv4/udp.c=1235=int udp_sendmsg(struct sock sk, struct msghdr msg, size_t len)\n--\nnet/ipv4/udp.c-1444-\t\tif (!IS_ERR_OR_NULL(skb))\nnet/ipv4/udp.c:1445:\t\t\terr = udp_send_skb(skb, fl4, \u0026cork);\nnet/ipv4/udp.c-1446-\t\tgoto out;\n" }
141/2	2026/07/07 03:12	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 67091 output: 37 thoughts: 50 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing: Analyzing the UDP Send Path Alright, so `udp_send_skb` is a critical path, a known hotspot, and I've seen it's been touched recently. That definitely means it needs to be included in my analysis. It's too important to skip over. Now, where do I start looking? Let's check `net/ipv6/udp.c`. It's likely that the IPv6 version, `udp_v6_send_skb`, will be the key function to examine there. I'll focus my investigation on that function and its interactions.
142/2	2026/07/07 03:12	tool	grepper	0m Args: { "Expression": "udp_v6_send_skb", "PathPrefix": "net/ipv6/udp.c" } Results: { "Output": "net/ipv6/udp.c=1313=static void udp6_hwcsum_outgoing(struct sock sk, struct sk_buff skb,\n--\nnet/ipv6/udp.c-1353-\nnet/ipv6/udp.c:1354:static int udp_v6_send_skb(struct sk_buff skb, struct flowi6 fl6,\nnet/ipv6/udp.c-1355-\t\t\t struct inet_cork cork)\n--\nnet/ipv6/udp.c=1436=static int udp_v6_push_pending_frames(struct sock sk)\n--\nnet/ipv6/udp.c-1448-\nnet/ipv6/udp.c:1449:\terr = udp_v6_send_skb(skb, \u0026inet_sk(sk)-\u003ecork.fl.u.ip6,\nnet/ipv6/udp.c-1450-\t\t\t \u0026inet_sk(sk)-\u003ecork.base);\n--\nnet/ipv6/udp.c=1457=int udpv6_sendmsg(struct sock sk, struct msghdr msg, size_t len)\n--\nnet/ipv6/udp.c-1710-\t\tif (!IS_ERR_OR_NULL(skb))\nnet/ipv6/udp.c:1711:\t\t\terr = udp_v6_send_skb(skb, fl6, \u0026cork.base);\nnet/ipv6/udp.c-1712-\t\t/* ip6_make_skb steals dst reference */\n" }
143/2	2026/07/07 03:12	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 67732 output: 32 thoughts: 48 Thoughts: Here's my analysis of the provided snippet, rendered as a first-person expert summary: Analyzing UDP Performance Hotspots Okay, so I'm diving into this UDP code, and the first thing that jumps out is that `udp_v6_send_skb` is a known performance bottleneck, a hot path. And even more interesting, it's been modified. That definitely needs to be included in my analysis; I need to understand those changes and their impact. Now, I'm heading over to the more general UDP code for IPv4, specifically `net/ipv4/udp.c`, just to get a broader understanding of the overall flow and any potential interactions or dependencies. I want to quickly refresh myself on the receive side, so `udp_rcv` is the function I will be investigating, the core receive function. I will be looking for interactions. I will also be looking for any clues about interactions with the IPv6 path.
144/2	2026/07/07 03:13	tool	grepper	0m Args: { "Expression": "udp_rcv", "PathPrefix": "net/ipv4/udp.c" } Results: { "Output": "net/ipv4/udp.c=1511=void udp_splice_eof(struct socket sock)\n--\nnet/ipv4/udp.c-1527-/ all head states (dst, sk, nf conntrack) except skb extensions are\nnet/ipv4/udp.c:1528: * cleared by udp_rcv().\nnet/ipv4/udp.c-1529- \n--\nnet/ipv4/udp.c=2424=static int udp_queue_rcv_skb(struct sock sk, struct sk_buff skb)\n--\nnet/ipv4/udp.c-2433-\t__skb_push(skb, -skb_mac_offset(skb));\nnet/ipv4/udp.c:2434:\tsegs = udp_rcv_segment(sk, skb, true);\nnet/ipv4/udp.c-2435-\tskb_list_walk_safe(segs, skb, next) {\n--\nnet/ipv4/udp.c=2568=static int udp_unicast_rcv_skb(struct sock sk, struct sk_buff skb,\n--\nnet/ipv4/udp.c-2589-\nnet/ipv4/udp.c:2590:int udp_rcv(struct sk_buff skb)\nnet/ipv4/udp.c-2591-{\n" }
145/2	2026/07/07 03:13	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 68380 output: 34 thoughts: 40
146/2	2026/07/07 03:13	tool	grepper	0m Args: { "Expression": "udpv6_rcv", "PathPrefix": "net/ipv6/udp.c" } Results: { "Output": "net/ipv6/udp.c=1035=static int udp6_csum_init(struct sk_buff skb, struct udphdr uh)\n--\nnet/ipv6/udp.c-1066-\nnet/ipv6/udp.c:1067:INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)\nnet/ipv6/udp.c-1068-{\n--\nnet/ipv6/udp.c=1937=int __init udpv6_init(void)\n--\nnet/ipv6/udp.c-1941-\tnet_hotdata.udpv6_protocol = (struct inet6_protocol) {\nnet/ipv6/udp.c:1942:\t\t.handler = udpv6_rcv,\nnet/ipv6/udp.c-1943-\t\t.err_handler = udpv6_err,\n" }
147/2	2026/07/07 03:13	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 68694 output: 27 thoughts: 1358 Thoughts: My UDP Optimization Strategy Okay, so `udpv6_rcv` is definitely a performance bottleneck; I'll be steering clear of that. The plan is to see what kind of configuration changes I can get away with, to improve performance. Let's start by looking at a list of functions that seem to touch UDP in various ways, to see if there are any that I can remove from the configuration: `__udp_gso_segment`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `__skb_udp_tunnel_segment`, `udp_gro_receive_segment`, `fou_build_udp`, `fou6_build_udp`, `esp_output_udp_encap`, `esp6_output_udp_encap`, `l2tp_xmit_core`, `ipvs_gue_encap`, `tso_build_hdr`, `skb_segment`, `amt_send_discovery`, `nsim_do_psp`, `psp_write_headers`, `nat_keepalive_send`, `tcf_csum_ipv4_udp`, `tcf_csum_ipv6_udp`, `nf_nat_mangle_udp_packet`, `udp_error`, `snmp_translate`, `udp_uncompress`, `prepare_skb_header`, `rdma_build_skb`, `rxe_udp_encap_recv`, `efx_gen_tun_header_udp`, `i40e_tso`, `iavf_tso`, `ice_tso`, `idpf_tso`, `otx2_sqe_add_ext`, `mlx5e_shampo_update_ipv4_udp_hdr`, `mlx5e_shampo_update_ipv6_udp_hdr`, `inet_rtm_getroute_build_skb`, `fill_packet_ipv4`, `fill_packet_ipv6`. That’s a good starting point. I could just disable these features and then start to profile it. Now, let's move on to the relevant kernel configuration options. I'll check these configs: `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, `IP_VS`, `AMT`, `WIREGUARD`, `6LOWPAN_NHC_UDP`, `NF_NAT_SNMP_BASIC`, `NET_ACT_CSUM`, `RDMA_RXE`, `NETDEVSIM`, and `INET_PSP`. A quick review: `INET_PSP` is PSP Security Protocol support, `NETDEVSIM` is the simulated networking device, `RDMA_RXE` is Software RDMA over Ethernet (RoCE) driver, `NET_ACT_CSUM` is Checksum Updating, `NF_NAT_SNMP_BASIC` is Basic SNMP-ALG support, `6LOWPAN_NHC_UDP` is UDP Header Support, `WIREGUARD` is WireGuard secure network tunnel, `AMT` is Automatic Multicast Tunneling (AMT), `IP_VS` is IP virtual server support, `L2TP` is Layer Two Tunneling Protocol (L2TP), `INET_ESP` is IP: ESP transformation, `INET6_ESP` is IPv6: ESP transformation, `NET_FOU` is IP: Foo (IP protocols) over UDP, `GENEVE` is Generic Network Virtualization Encapsulation, and `VXLAN` is Virtual eXtensible Local Area Network (VXLAN). I'll also include `NET_UDP_TUNNEL` just in case, but it's often enabled by `VXLAN` and `GENEVE`. Now I should be able to start testing the configuration and see how the performance numbers change.
148/2	2026/07/07 03:13	tool	grepper	0m Args: { "Expression": "config NET_UDP_TUNNEL", "PathPrefix": "" } Results: { "Output": "net/ipv4/Kconfig=304=config NET_IPVTI\n--\nnet/ipv4/Kconfig-315-\nnet/ipv4/Kconfig:316:config NET_UDP_TUNNEL\nnet/ipv4/Kconfig-317-\ttristate\n" }
149/2	2026/07/07 03:13	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 71027 output: 25 thoughts: 41 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, as if they were my own: Tristate Selection and Configuration Review Alright, this is a tristate, and crucially, it's not being driven by a direct prompt. That immediately flags it as being selected by other configuration options, so there's no need to explicitly document it or think of it that way. My focus is going to be elsewhere. I need to understand why it's being selected, its dependencies, and its impact on the final configuration. Let me just quickly verify `CONFIG_INET_PSP`. I want to make sure the relevant config is what I expect. I need to be sure the system is behaving as I anticipate.
150/2	2026/07/07 03:13	tool	grepper	0m Args: { "Expression": "config INET_PSP", "PathPrefix": "" } Results: { "Output": "net/psp/Kconfig-4-#\nnet/psp/Kconfig:5:config INET_PSP\nnet/psp/Kconfig-6-\tbool \"PSP Security Protocol support\"\n" }
151/2	2026/07/07 03:13	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 71308 output: 25 thoughts: 24 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Quick Verification & Next Steps Alright, yep, confirmed. `INET_PSP` is definitely the right variable to be focusing on here. No need to second-guess that initial assessment. Now, given that confirmation, I think we should probably double-check that `CONFIG_NETDEVSIM` flag. That variable often plays a pivotal role in the kinds of interactions we're talking about, and it's always smart to have that one firmly in mind for the path forward. It's a key piece of the puzzle.
152/2	2026/07/07 03:14	tool	grepper	0m Args: { "Expression": "config NETDEVSIM", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=602=source \"drivers/net/hyperv/Kconfig\"\ndrivers/net/Kconfig-603-\ndrivers/net/Kconfig:604:config NETDEVSIM\ndrivers/net/Kconfig-605-\ttristate \"Simulated networking device\"\n" }
153/2	2026/07/07 03:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 71577 output: 26 thoughts: 26 Thoughts: Okay, here's my summary, presented as a stream of thought: Checking the RDMA Configuration Right, `NETDEVSIM` looks good, that aligns with my expectations. Always good to have that confirmation. Now, let's just quickly double-check that `CONFIG_RDMA_RXE` is enabled. It's crucial for the RDMA path, and I need to be absolutely certain it's correctly configured given the current circumstances. Making sure this configuration parameter is correct will ensure that there are no issues in running RDMA over the virtual network.
154/2	2026/07/07 03:14	tool	grepper	0m Args: { "Expression": "config RDMA_RXE", "PathPrefix": "" } Results: { "Output": "drivers/infiniband/sw/rxe/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/sw/rxe/Kconfig:2:config RDMA_RXE\ndrivers/infiniband/sw/rxe/Kconfig-3-\ttristate \"Software RDMA over Ethernet (RoCE) driver\"\n" }
155/2	2026/07/07 03:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 71852 output: 27 thoughts: 28 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Checking RDMA Configuration Right, `RDMA_RXE` is definitely the correct flag. No need to second-guess that. Now, just to be absolutely certain and to cover all our bases, let's just quickly confirm that `CONFIG_NET_ACT_CSUM` is enabled as well. It's a quick sanity check that often catches those subtle, but crucial, dependencies. Can't be too careful when dealing with network performance.
156/2	2026/07/07 03:14	tool	grepper	0m Args: { "Expression": "config NET_ACT_CSUM", "PathPrefix": "" } Results: { "Output": "net/sched/Kconfig=797=config NET_ACT_SKBEDIT\n--\nnet/sched/Kconfig-807-\nnet/sched/Kconfig:808:config NET_ACT_CSUM\nnet/sched/Kconfig-809-\ttristate \"Checksum Updating\"\n" }
157/2	2026/07/07 03:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 72112 output: 29 thoughts: 31 Thoughts: Okay, here's my take on those thoughts, framed as my own: Quick Verification & Next Steps Yep, `NET_ACT_CSUM` is definitely the right parameter for that. Seems straightforward enough. Now, before I move on, I should quickly verify the status of `CONFIG_NF_NAT_SNMP_BASIC`. I vaguely recall something about that potentially impacting the setup, so a quick confirmation will save me any backtracking later. Just a quick double-check to ensure smooth sailing.
158/2	2026/07/07 03:14	tool	grepper	0m Args: { "Expression": "config NF_NAT_SNMP_BASIC", "PathPrefix": "" } Results: { "Output": "net/ipv4/netfilter/Kconfig=99=if NF_NAT\nnet/ipv4/netfilter/Kconfig:100:config NF_NAT_SNMP_BASIC\nnet/ipv4/netfilter/Kconfig-101-\ttristate \"Basic SNMP-ALG support\"\n" }
159/2	2026/07/07 03:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 72362 output: 30 thoughts: 33 Thoughts: Okay, here's my take on those thoughts, framed as my own reasoning: Checking the Configuration Parameters Alright, yep, I'm confirming that `NF_NAT_SNMP_BASIC` is definitely the right choice in this scenario. Makes perfect sense given the context. Now, just to be absolutely thorough, I want to quickly verify `CONFIG_6LOWPAN_NHC_UDP` while I'm at it. Gotta make sure everything's ship-shape and secure.
160/2	2026/07/07 03:15	tool	grepper	0m Args: { "Expression": "config 6LOWPAN_NHC_UDP", "PathPrefix": "" } Results: { "Output": "net/6lowpan/Kconfig=59=config 6LOWPAN_NHC_ROUTING\n--\nnet/6lowpan/Kconfig-64-\nnet/6lowpan/Kconfig:65:config 6LOWPAN_NHC_UDP\nnet/6lowpan/Kconfig-66-\ttristate \"UDP Header Support\"\n" }
161/2	2026/07/07 03:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 72627 output: 25 thoughts: 29 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing: Quick Verification & Next Steps Yep, I'm confident that `6LOWPAN_NHC_UDP` is the right configuration option here. That's settled. Now, before I move on to the next task, I should just quickly double-check the status of `CONFIG_WIREGUARD`. It's always a good practice to confirm the status of related configurations, especially when moving between distinct feature sets. I want to make sure I'm not missing anything that could impact the overall system configuration. Just a quick sanity check to avoid any future surprises.
162/2	2026/07/07 03:15	tool	grepper	0m Args: { "Expression": "config WIREGUARD", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=59=config DUMMY\n--\ndrivers/net/Kconfig-73-\ndrivers/net/Kconfig:74:config WIREGUARD\ndrivers/net/Kconfig-75-\ttristate \"WireGuard secure network tunnel\"\n--\ndrivers/net/Kconfig-91-\ndrivers/net/Kconfig:92:config WIREGUARD_DEBUG\ndrivers/net/Kconfig-93-\tbool \"Debugging checks and verbose messages\"\n" }
163/2	2026/07/07 03:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 72949 output: 22 thoughts: 22 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Confirmation and a Quick Check Yes, that's right, `WIREGUARD` is definitely the key here. That's the correct initial assessment. Now, just to be absolutely certain, let's take a quick look at `CONFIG_AMT` again. We'll rule it out, and then we're free to focus on the area of `WIREGUARD` that needs the most attention.
164/2	2026/07/07 03:15	tool	grepper	0m Args: { "Expression": "config AMT", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=289=config PFCP\n--\ndrivers/net/Kconfig-301-\ndrivers/net/Kconfig:302:config AMT\ndrivers/net/Kconfig-303-\ttristate \"Automatic Multicast Tunneling (AMT)\"\n" }
165/2	2026/07/07 03:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 73184 output: 24 thoughts: 21 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Confirming & Refining Assumptions Alright, that initial assessment regarding `AMT` seems spot-on. No need to second-guess that. Now, let's just quickly verify the state of `CONFIG_IP_VS`. While it's likely where I expect it to be, a quick double-check always helps avoid a potential gotcha down the line. It's about being thorough, even with things that feel self-evident. A simple verification here saves time in the long run.
166/2	2026/07/07 03:15	tool	grepper	0m Args: { "Expression": "config IP_VS", "PathPrefix": "" } Results: { "Output": "net/netfilter/ipvs/Kconfig-4-#\nnet/netfilter/ipvs/Kconfig:5:menuconfig IP_VS\nnet/netfilter/ipvs/Kconfig-6-\ttristate \"IP virtual server support\"\n--\nnet/netfilter/ipvs/Kconfig=286=comment 'IPVS SH scheduler'\nnet/netfilter/ipvs/Kconfig-287-\nnet/netfilter/ipvs/Kconfig:288:config IP_VS_SH_TAB_BITS\nnet/netfilter/ipvs/Kconfig-289-\tint \"IPVS source hashing table size (the Nth power of 2)\"\n--\nnet/netfilter/ipvs/Kconfig=301=comment 'IPVS MH scheduler'\nnet/netfilter/ipvs/Kconfig-302-\nnet/netfilter/ipvs/Kconfig:303:config IP_VS_MH_TAB_INDEX\nnet/netfilter/ipvs/Kconfig-304-\tint \"IPVS maglev hashing table index of size (the prime numbers)\"\n" }
167/2	2026/07/07 03:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 73621 output: 24 thoughts: 23 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: Quick Verification & Next Steps Right, `IP_VS` is definitely the correct place to start. That checks out; I'm satisfied with that. Now, just to make absolutely certain, I'll quickly glance over `CONFIG_L2TP`. Need to ensure there are no subtle interactions or dependencies that I've missed. Might as well rule it out while it's fresh in my mind. Just a quick sanity check to avoid any potential headaches down the line.
168/2	2026/07/07 03:15	tool	grepper	0m Args: { "Expression": "config L2TP", "PathPrefix": "" } Results: { "Output": "net/l2tp/Kconfig-5-\nnet/l2tp/Kconfig:6:menuconfig L2TP\nnet/l2tp/Kconfig-7-\ttristate \"Layer Two Tunneling Protocol (L2TP)\"\n--\nnet/l2tp/Kconfig-35-\nnet/l2tp/Kconfig:36:config L2TP_DEBUGFS\nnet/l2tp/Kconfig-37-\ttristate \"L2TP debugfs support\"\n--\nnet/l2tp/Kconfig-48-\nnet/l2tp/Kconfig:49:config L2TP_V3\nnet/l2tp/Kconfig-50-\tbool \"L2TPv3 support\"\n--\nnet/l2tp/Kconfig-69-\nnet/l2tp/Kconfig:70:config L2TP_IP\nnet/l2tp/Kconfig-71-\ttristate \"L2TP IP encapsulation for L2TPv3\"\n--\nnet/l2tp/Kconfig-86-\nnet/l2tp/Kconfig:87:config L2TP_ETH\nnet/l2tp/Kconfig-88-\ttristate \"L2TP ethernet pseudowire support for L2TPv3\"\n" }
169/2	2026/07/07 03:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 74106 output: 25 thoughts: 32 Thoughts: Okay, here's my take on those thoughts, framed as my own: Verifying the VPN Configuration Alright, yep, that's right, `L2TP` is definitely the right protocol we're dealing with. Now, just to be absolutely certain and to make sure we're covering all the bases, I need to quickly double-check that the proper IPsec ESP support is enabled. Let me just confirm that `CONFIG_INET_ESP` and `CONFIG_INET6_ESP` are set as expected. Better safe than sorry when dealing with security, right? Making sure everything is locked down nice and tight is crucial.
170/2	2026/07/07 03:16	tool	grepper	0m Args: { "Expression": "config INET_ESP", "PathPrefix": "" } Results: { "Output": "net/ipv4/Kconfig=339=config INET_AH\n--\nnet/ipv4/Kconfig-353-\nnet/ipv4/Kconfig:354:config INET_ESP\nnet/ipv4/Kconfig-355-\ttristate \"IP: ESP transformation\"\n--\nnet/ipv4/Kconfig-368-\nnet/ipv4/Kconfig:369:config INET_ESP_OFFLOAD\nnet/ipv4/Kconfig-370-\ttristate \"IP: ESP transformation offload\"\n--\nnet/ipv4/Kconfig-381-\nnet/ipv4/Kconfig:382:config INET_ESPINTCP\nnet/ipv4/Kconfig-383-\tbool \"IP: ESP in TCP encapsulation (RFC 8229)\"\n" }
171/2	2026/07/07 03:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 74511 output: 25 thoughts: 31 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: ESP and FOU Verification Alright, yep, confirming that `INET_ESP` and `INET6_ESP` are the appropriate defines for ESP over IPv4 and IPv6 respectively. Nothing to question there. Now, just to be absolutely certain – and because it’s a good habit – let’s quickly verify the configuration option for FOU. Specifically, I need to make sure `CONFIG_NET_FOU` is set appropriately, especially considering our project's requirements. This is a crucial area and a quick double-check never hurts, given how closely these things often interact.
172/2	2026/07/07 03:16	tool	grepper	0m Args: { "Expression": "config NET_FOU", "PathPrefix": "" } Results: { "Output": "net/ipv4/Kconfig=316=config NET_UDP_TUNNEL\n--\nnet/ipv4/Kconfig-320-\nnet/ipv4/Kconfig:321:config NET_FOU\nnet/ipv4/Kconfig-322-\ttristate \"IP: Foo (IP protocols) over UDP\"\n--\nnet/ipv4/Kconfig-329-\nnet/ipv4/Kconfig:330:config NET_FOU_IP_TUNNELS\nnet/ipv4/Kconfig-331-\tbool \"IP: FOU encapsulation of IP tunnels\"\n" }
173/2	2026/07/07 03:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 74866 output: 24 thoughts: 24 Thoughts: Okay, here's my summary, presented as a stream of thought: Confirming and Cross-Referencing Alright, yep, that `NET_FOU` setting, the one we've been looking at – that's definitely correct. No need to second-guess that. Good. Now, just to be completely thorough, let's circle back and quickly verify that `CONFIG_GENEVE` option. I want to make sure there are no downstream implications or overlooked dependencies. It's always best practice to double-check related configurations, even when you're reasonably sure, just to keep things airtight. Let's see...
174/2	2026/07/07 03:16	tool	grepper	0m Args: { "Expression": "config GENEVE", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=230=config VXLAN\n--\ndrivers/net/Kconfig-244-\ndrivers/net/Kconfig:245:config GENEVE\ndrivers/net/Kconfig-246-\ttristate \"Generic Network Virtualization Encapsulation\"\n" }
175/2	2026/07/07 03:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 75133 output: 23 thoughts: 22 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person: Confirming and Cross-Referencing Configuration Right, `GENEVE` is definitely the protocol we're working with here. That's settled. But I always like to be thorough, especially when it comes to networking and potential dependencies. Let's just quickly verify the state of `CONFIG_VXLAN` to ensure there are no unforeseen conflicts or interactions. A quick sanity check now could save a headache later. Just making sure everything lines up as it should.
176/2	2026/07/07 03:16	tool	grepper	0m Args: { "Expression": "config VXLAN", "PathPrefix": "" } Results: { "Output": "drivers/net/Kconfig=216=config IPVTAP\n--\ndrivers/net/Kconfig-229-\ndrivers/net/Kconfig:230:config VXLAN\ndrivers/net/Kconfig-231-\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\n" }
177/2	2026/07/07 03:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 75386 output: 654 thoughts: 16 Thoughts: Here's your summary: VXLAN Confirmation and Result Finalization Okay, yes, I've confirmed it. My assessment of the situation points directly to `VXLAN`. This is the correct solution given the parameters. I'm satisfied with the findings. Now, I'm ready to finalize these results and present them with confidence. It's time to put a bow on this.
178/2	2026/07/07 03:16	tool	set-results	0m Args: { "EnableConfigs": [ "VXLAN", "GENEVE", "NET_FOU", "INET_ESP", "INET6_ESP", "L2TP", "IP_VS", "AMT", "WIREGUARD", "6LOWPAN_NHC_UDP", "NF_NAT_SNMP_BASIC", "NET_ACT_CSUM", "RDMA_RXE", "NETDEVSIM", "INET_PSP" ], "FocusSymbols": [ "__udp_gso_segment", "udp_gro_complete", "udp4_gro_complete", "udp6_gro_complete", "udp_tunnel_xmit_skb", "udp_tunnel6_xmit_skb", "__skb_udp_tunnel_segment", "udp_gro_receive_segment", "fou_build_udp", "fou6_build_udp", "esp_output_udp_encap", "esp6_output_udp_encap", "l2tp_xmit_core", "ipvs_gue_encap", "tso_build_hdr", "skb_segment", "amt_send_discovery", "nsim_do_psp", "psp_write_headers", "nat_keepalive_send", "tcf_csum_ipv4_udp", "tcf_csum_ipv6_udp", "nf_nat_mangle_udp_packet", "udp_error", "snmp_translate", "udp_uncompress", "prepare_skb_header", "rdma_build_skb", "rxe_udp_encap_recv", "efx_gen_tun_header_udp", "i40e_tso", "iavf_tso", "ice_tso", "idpf_tso", "otx2_sqe_add_ext", "mlx5e_shampo_update_ipv4_udp_hdr", "mlx5e_shampo_update_ipv6_udp_hdr", "inet_rtm_getroute_build_skb", "fill_packet_ipv4", "fill_packet_ipv6" ], "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "VXLAN", "GENEVE", "NET_FOU", "INET_ESP", "INET6_ESP", "L2TP", "IP_VS", "AMT", "WIREGUARD", "6LOWPAN_NHC_UDP", "NF_NAT_SNMP_BASIC", "NET_ACT_CSUM", "RDMA_RXE", "NETDEVSIM", "INET_PSP" ], "FocusSymbols": [ "__udp_gso_segment", "udp_gro_complete", "udp4_gro_complete", "udp6_gro_complete", "udp_tunnel_xmit_skb", "udp_tunnel6_xmit_skb", "__skb_udp_tunnel_segment", "udp_gro_receive_segment", "fou_build_udp", "fou6_build_udp", "esp_output_udp_encap", "esp6_output_udp_encap", "l2tp_xmit_core", "ipvs_gue_encap", "tso_build_hdr", "skb_segment", "amt_send_discovery", "nsim_do_psp", "psp_write_headers", "nat_keepalive_send", "tcf_csum_ipv4_udp", "tcf_csum_ipv6_udp", "nf_nat_mangle_udp_packet", "udp_error", "snmp_translate", "udp_uncompress", "prepare_skb_header", "rdma_build_skb", "rxe_udp_encap_recv", "efx_gen_tun_header_udp", "i40e_tso", "iavf_tso", "ice_tso", "idpf_tso", "otx2_sqe_add_ext", "mlx5e_shampo_update_ipv4_udp_hdr", "mlx5e_shampo_update_ipv6_udp_hdr", "inet_rtm_getroute_build_skb", "fill_packet_ipv4", "fill_packet_ipv6" ], "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.", "WorthFuzzing": true }

Trajectory: (Expand/Collapse All)

Seq

Timestamp

Type

Name

Duration

0/0

2026/07/07 02:47

flow

patch-triage

29m

Args:

null

Results:

{
  "EnableConfigs": [
    "VXLAN",
    "GENEVE",
    "NET_FOU",
    "INET_ESP",
    "INET6_ESP",
    "L2TP",
    "IP_VS",
    "AMT",
    "WIREGUARD",
    "6LOWPAN_NHC_UDP",
    "NF_NAT_SNMP_BASIC",
    "NET_ACT_CSUM",
    "RDMA_RXE",
    "NETDEVSIM",
    "INET_PSP"
  ],
  "FocusSymbols": [
    "__udp_gso_segment",
    "udp_gro_complete",
    "udp4_gro_complete",
    "udp6_gro_complete",
    "udp_tunnel_xmit_skb",
    "udp_tunnel6_xmit_skb",
    "__skb_udp_tunnel_segment",
    "udp_gro_receive_segment",
    "fou_build_udp",
    "fou6_build_udp",
    "esp_output_udp_encap",
    "esp6_output_udp_encap",
    "l2tp_xmit_core",
    "ipvs_gue_encap",
    "tso_build_hdr",
    "skb_segment",
    "amt_send_discovery",
    "nsim_do_psp",
    "psp_write_headers",
    "nat_keepalive_send",
    "tcf_csum_ipv4_udp",
    "tcf_csum_ipv6_udp",
    "nf_nat_mangle_udp_packet",
    "udp_error",
    "snmp_translate",
    "udp_uncompress",
    "prepare_skb_header",
    "rdma_build_skb",
    "rxe_udp_encap_recv",
    "efx_gen_tun_header_udp",
    "i40e_tso",
    "iavf_tso",
    "ice_tso",
    "idpf_tso",
    "otx2_sqe_add_ext",
    "mlx5e_shampo_update_ipv4_udp_hdr",
    "mlx5e_shampo_update_ipv6_udp_hdr",
    "inet_rtm_getroute_build_skb",
    "fill_packet_ipv4",
    "fill_packet_ipv6"
  ],
  "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.",
  "WorthFuzzing": true
}

1/1

2026/07/07 02:47

action

read-patch-diff

Args:

null

Results:

{
  "PatchDiff": "commit a82ad991569e9e2986e7c0d714f5587f5ee69273\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jul 7 02:47:49 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/infiniband/core/lag.c b/drivers/infiniband/core/lag.c\nindex 8fd80adfe833e7..00fe241737ffee 100644\n--- a/drivers/infiniband/core/lag.c\n+++ b/drivers/infiniband/core/lag.c\n@@ -36,7 +36,7 @@ static struct sk_buff *rdma_build_skb(struct net_device *netdev,\n \tuh-\u003esource =\n \t\thtons(rdma_flow_label_to_udp_sport(ah_attr-\u003egrh.flow_label));\n \tuh-\u003edest = htons(ROCE_V2_UDP_DPORT);\n-\tuh-\u003elen = htons(sizeof(struct udphdr));\n+\tudp_set_len_short(uh, sizeof(struct udphdr));\n \n \tif (is_ipv4) {\n \t\tskb_push(skb, sizeof(struct iphdr));\ndiff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c\nindex 3741b2c4b0bbfd..53daaf4c1eb2e0 100644\n--- a/drivers/infiniband/sw/rxe/rxe_net.c\n+++ b/drivers/infiniband/sw/rxe/rxe_net.c\n@@ -242,7 +242,7 @@ static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)\n \tpkt-\u003eport_num = 1;\n \tpkt-\u003ehdr = (u8 *)(udph + 1);\n \tpkt-\u003emask = RXE_GRH_MASK;\n-\tpkt-\u003epaylen = be16_to_cpu(udph-\u003elen) - sizeof(*udph);\n+\tpkt-\u003epaylen = udp_get_len_short(udph) - sizeof(*udph);\n \n \t/* remove udp header */\n \tskb_pull(skb, sizeof(struct udphdr));\n@@ -305,7 +305,7 @@ static void prepare_udp_hdr(struct sk_buff *skb, __be16 src_port,\n \n \tudph-\u003edest = dst_port;\n \tudph-\u003esource = src_port;\n-\tudph-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len_short(udph, skb-\u003elen);\n \tudph-\u003echeck = 0;\n }\n \ndiff --git a/drivers/net/amt.c b/drivers/net/amt.c\nindex 5cf97c65576fc2..a44ffbb1816523 100644\n--- a/drivers/net/amt.c\n+++ b/drivers/net/amt.c\n@@ -667,7 +667,7 @@ static void amt_send_discovery(struct amt_dev *amt)\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003egw_port;\n \tudph-\u003edest\t= amt-\u003erelay_port;\n-\tudph-\u003elen\t= htons(sizeof(*udph) + sizeof(*amtd));\n+\tudp_set_len_short(udph, sizeof(*udph) + sizeof(*amtd));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n@@ -760,7 +760,7 @@ static void amt_send_request(struct amt_dev *amt, bool v6)\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003egw_port;\n \tudph-\u003edest\t= amt-\u003erelay_port;\n-\tudph-\u003elen\t= htons(sizeof(*amtrh) + sizeof(*udph));\n+\tudp_set_len_short(udph, sizeof(*amtrh) + sizeof(*udph));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n@@ -2611,7 +2611,7 @@ static void amt_send_advertisement(struct amt_dev *amt, __be32 nonce,\n \tudph\t\t= udp_hdr(skb);\n \tudph-\u003esource\t= amt-\u003erelay_port;\n \tudph-\u003edest\t= dport;\n-\tudph-\u003elen\t= htons(sizeof(*amta) + sizeof(*udph));\n+\tudp_set_len_short(udph, sizeof(*amta) + sizeof(*udph));\n \tudph-\u003echeck\t= 0;\n \toffset = skb_transport_offset(skb);\n \tskb-\u003ecsum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\ndiff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c\nindex 894f2d06d39d07..ef5e657816f005 100644\n--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c\n+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c\n@@ -3129,7 +3129,7 @@ static int i40e_tso(struct i40e_tx_buffer *first, u8 *hdr_len,\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t    (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/* determine offset of outer transport header */\n \t\t\tl4_offset = l4.hdr - skb-\u003edata;\ndiff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c\nindex 363c42bf3dcfee..c30abf17cf5d3c 100644\n--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c\n+++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c\n@@ -1774,7 +1774,7 @@ static int iavf_tso(struct iavf_tx_buffer *first, u8 *hdr_len,\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t    (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/* determine offset of outer transport header */\n \t\t\tl4_offset = l4.hdr - skb-\u003edata;\ndiff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c\nindex 4ca1a0602307d0..fdea2758adf155 100644\n--- a/drivers/net/ethernet/intel/ice/ice_txrx.c\n+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c\n@@ -1893,7 +1893,7 @@ int ice_tso(struct ice_tx_buf *first, struct ice_tx_offload_params *off)\n \t\t\t\t\t SKB_GSO_UDP_TUNNEL_CSUM)) {\n \t\tif (!(skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_PARTIAL) \u0026\u0026\n \t\t    (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_TUNNEL_CSUM)) {\n-\t\t\tl4.udp-\u003elen = 0;\n+\t\t\tudp_set_len_short(l4.udp, 0);\n \n \t\t\t/* determine offset of outer transport header */\n \t\t\tl4_start = (u8)(l4.hdr - skb-\u003edata);\ndiff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c\nindex 7f9056404f64fc..566b08ca3a6cb1 100644\n--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c\n+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c\n@@ -2871,7 +2871,7 @@ int idpf_tso(struct sk_buff *skb, struct idpf_tx_offload_params *off)\n \t\t\t\t     (__force __wsum)htonl(paylen));\n \t\t/* compute length of segmentation header */\n \t\toff-\u003etso_hdr_len = sizeof(struct udphdr) + l4_start;\n-\t\tl4.udp-\u003elen = htons(shinfo-\u003egso_size + sizeof(struct udphdr));\n+\t\tudp_set_len_short(l4.udp, shinfo-\u003egso_size + sizeof(struct udphdr));\n \t\tbreak;\n \tdefault:\n \t\treturn -EINVAL;\ndiff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\nindex 625bb5a05344c0..8d2d607bc92f9c 100644\n--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\n+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c\n@@ -750,7 +750,7 @@ static void otx2_sqe_add_ext(struct otx2_nic *pfvf, struct otx2_snd_queue *sq,\n \t\t\t\text-\u003elso_format = pfvf-\u003ehw.lso_udpv6_idx;\n \t\t\t}\n \n-\t\t\tudph-\u003elen = htons(sizeof(struct udphdr));\n+\t\t\tudp_set_len_short(udph, sizeof(struct udphdr));\n \t\t}\n \t} else if (skb_shinfo(skb)-\u003etx_flags \u0026 SKBTX_HW_TSTAMP) {\n \t\text-\u003etstmp = 1;\ndiff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\nindex 6fbc0441c4b845..04af54b704d823 100644\n--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\n+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c\n@@ -1081,7 +1081,7 @@ static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq *rq, struct iphdr *\n \tstruct udphdr *uh;\n \n \tuh = (struct udphdr *)(skb-\u003edata + udp_off);\n-\tuh-\u003elen = htons(skb-\u003elen - udp_off);\n+\tudp_set_len_short(uh, skb-\u003elen - udp_off);\n \n \tif (uh-\u003echeck)\n \t\tuh-\u003echeck = ~udp_v4_check(skb-\u003elen - udp_off, ipv4-\u003esaddr,\n@@ -1100,7 +1100,7 @@ static void mlx5e_shampo_update_ipv6_udp_hdr(struct mlx5e_rq *rq, struct ipv6hdr\n \tstruct udphdr *uh;\n \n \tuh = (struct udphdr *)(skb-\u003edata + udp_off);\n-\tuh-\u003elen = htons(skb-\u003elen - udp_off);\n+\tudp_set_len_short(uh, skb-\u003elen - udp_off);\n \n \tif (uh-\u003echeck)\n \t\tuh-\u003echeck = ~udp_v6_check(skb-\u003elen - udp_off, \u0026ipv6-\u003esaddr,\ndiff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\nindex accc26d1a872db..1dcdb86690bb74 100644\n--- a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\n+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c\n@@ -113,7 +113,7 @@ static struct sk_buff *mlx5e_test_get_udp_skb(struct mlx5e_priv *priv)\n \t/* Fill UDP header */\n \tudph-\u003esource = htons(9);\n \tudph-\u003edest = htons(9); /* Discard Protocol */\n-\tudph-\u003elen = htons(sizeof(struct mlx5ehdr) + sizeof(struct udphdr));\n+\tudp_set_len_short(udph, sizeof(struct mlx5ehdr) + sizeof(struct udphdr));\n \tudph-\u003echeck = 0;\n \n \t/* Fill IP header */\ndiff --git a/drivers/net/ethernet/sfc/falcon/selftest.c b/drivers/net/ethernet/sfc/falcon/selftest.c\nindex db4dd7fb77f5cb..4d29e0baf2ebe5 100644\n--- a/drivers/net/ethernet/sfc/falcon/selftest.c\n+++ b/drivers/net/ethernet/sfc/falcon/selftest.c\n@@ -401,8 +401,8 @@ static void ef4_iterate_state(struct ef4_nic *efx)\n \n \t/* Initialise udp header */\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(*payload) -\n-\t\t\t\t offsetof(struct ef4_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(*payload) -\n+\t\t\t  offsetof(struct ef4_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/* checksum ignored */\n \n \t/* Fill out payload */\ndiff --git a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c\nindex 8ec76329237a49..dc716feb79cb5a 100644\n--- a/drivers/net/ethernet/sfc/selftest.c\n+++ b/drivers/net/ethernet/sfc/selftest.c\n@@ -398,8 +398,8 @@ static void efx_iterate_state(struct efx_nic *efx)\n \n \t/* Initialise udp header */\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(*payload) -\n-\t\t\t\t offsetof(struct efx_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(*payload) -\n+\t\t\t  offsetof(struct efx_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/* checksum ignored */\n \n \t/* Fill out payload */\ndiff --git a/drivers/net/ethernet/sfc/siena/selftest.c b/drivers/net/ethernet/sfc/siena/selftest.c\nindex 930643612df511..c74cf51313643d 100644\n--- a/drivers/net/ethernet/sfc/siena/selftest.c\n+++ b/drivers/net/ethernet/sfc/siena/selftest.c\n@@ -399,8 +399,8 @@ static void efx_iterate_state(struct efx_nic *efx)\n \n \t/* Initialise udp header */\n \tpayload-\u003eudp.source = 0;\n-\tpayload-\u003eudp.len = htons(sizeof(*payload) -\n-\t\t\t\t offsetof(struct efx_loopback_payload, udp));\n+\tudp_set_len_short(\u0026payload-\u003eudp, sizeof(*payload) -\n+\t\t\t  offsetof(struct efx_loopback_payload, udp));\n \tpayload-\u003eudp.check = 0;\t/* checksum ignored */\n \n \t/* Fill out payload */\ndiff --git a/drivers/net/ethernet/sfc/tc_encap_actions.c b/drivers/net/ethernet/sfc/tc_encap_actions.c\nindex db222abef53b2a..c2ad3a358d2012 100644\n--- a/drivers/net/ethernet/sfc/tc_encap_actions.c\n+++ b/drivers/net/ethernet/sfc/tc_encap_actions.c\n@@ -311,7 +311,7 @@ static void efx_gen_tun_header_udp(struct efx_tc_encap_action *encap, u8 len)\n \tencap-\u003eencap_hdr_len += sizeof(*udp);\n \n \tudp-\u003edest = key-\u003etp_dst;\n-\tudp-\u003elen = cpu_to_be16(sizeof(*udp) + len);\n+\tudp_set_len_short(udp, sizeof(*udp) + len);\n }\n \n static void efx_gen_tun_header_vxlan(struct efx_tc_encap_action *encap)\ndiff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\nindex a0c75886587c35..29e824bd90ca6b 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c\n@@ -154,9 +154,9 @@ static struct sk_buff *stmmac_test_get_udp_skb(struct stmmac_priv *priv,\n \t} else {\n \t\tuhdr-\u003esource = htons(attr-\u003esport);\n \t\tuhdr-\u003edest = htons(attr-\u003edport);\n-\t\tuhdr-\u003elen = htons(sizeof(*shdr) + sizeof(*uhdr) + attr-\u003esize);\n+\t\tudp_set_len_short(uhdr, sizeof(*shdr) + sizeof(*uhdr) + attr-\u003esize);\n \t\tif (attr-\u003emax_size)\n-\t\t\tuhdr-\u003elen = htons(attr-\u003emax_size -\n+\t\t\tudp_set_len_short(uhdr, attr-\u003emax_size -\n \t\t\t\t\t  (sizeof(*ihdr) + sizeof(*ehdr)));\n \t\tuhdr-\u003echeck = 0;\n \t}\ndiff --git a/drivers/net/geneve.c b/drivers/net/geneve.c\nindex 396e1a113cd49e..a1639ad53077ec 100644\n--- a/drivers/net/geneve.c\n+++ b/drivers/net/geneve.c\n@@ -631,7 +631,7 @@ static int geneve_post_decap_hint(const struct sock *sk, struct sk_buff *skb,\n \n \t/* Adjust the nested UDP header len and checksum. */\n \tuh = udp_hdr(skb);\n-\tuh-\u003elen = htons(skb-\u003elen - gro_hint-\u003enested_tp_offset);\n+\tudp_set_len_short(uh, skb-\u003elen - gro_hint-\u003enested_tp_offset);\n \tif (uh-\u003echeck) {\n \t\tlen = skb-\u003elen - gro_hint-\u003enested_tp_offset;\n \t\tskb_shinfo(skb)-\u003egso_type |= SKB_GSO_UDP_TUNNEL_CSUM;\n@@ -1745,6 +1745,8 @@ static void geneve_setup(struct net_device *dev)\n \tdev-\u003emax_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev-\u003ehard_header_len;\n \n \tnetif_keep_dst(dev);\n+\tnetif_set_tso_max_size(dev, GSO_MAX_SIZE);\n+\n \tdev-\u003epriv_flags \u0026= ~IFF_TX_SKB_SHARING;\n \tdev-\u003epriv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_NO_QUEUE;\n \tdev-\u003elltx = true;\ndiff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c\nindex c1812a98365b78..a531548eb89138 100644\n--- a/drivers/net/netconsole.c\n+++ b/drivers/net/netconsole.c\n@@ -1792,7 +1792,7 @@ static void push_udp(struct netpoll *np, struct sk_buff *skb, int len)\n \tudph = udp_hdr(skb);\n \tudph-\u003esource = htons(np-\u003elocal_port);\n \tudph-\u003edest = htons(np-\u003eremote_port);\n-\tudph-\u003elen = htons(udp_len);\n+\tudp_set_len_short(udph, udp_len);\n \n \tnetpoll_udp_checksum(np, skb, len);\n }\ndiff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c\nindex aed9ad5f1b43af..f65b4cf4ea392b 100644\n--- a/drivers/net/netdevsim/dev.c\n+++ b/drivers/net/netdevsim/dev.c\n@@ -845,7 +845,7 @@ static struct sk_buff *nsim_dev_trap_skb_build(void)\n \tudph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);\n \tget_random_bytes(\u0026udph-\u003esource, sizeof(u16));\n \tget_random_bytes(\u0026udph-\u003edest, sizeof(u16));\n-\tudph-\u003elen = htons(sizeof(struct udphdr) + data_len);\n+\tudp_set_len_short(udph, sizeof(struct udphdr) + data_len);\n \n \treturn skb;\n }\ndiff --git a/drivers/net/netdevsim/psample.c b/drivers/net/netdevsim/psample.c\nindex 717d157c3ae2b6..1e71c3da4def52 100644\n--- a/drivers/net/netdevsim/psample.c\n+++ b/drivers/net/netdevsim/psample.c\n@@ -73,7 +73,7 @@ static struct sk_buff *nsim_dev_psample_skb_build(void)\n \tudph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);\n \tget_random_bytes(\u0026udph-\u003esource, sizeof(u16));\n \tget_random_bytes(\u0026udph-\u003edest, sizeof(u16));\n-\tudph-\u003elen = htons(sizeof(struct udphdr) + data_len);\n+\tudp_set_len_short(udph, sizeof(struct udphdr) + data_len);\n \n \treturn skb;\n }\ndiff --git a/drivers/net/netdevsim/psp.c b/drivers/net/netdevsim/psp.c\nindex 59c990fdc79ecd..6b3532b5e360d5 100644\n--- a/drivers/net/netdevsim/psp.c\n+++ b/drivers/net/netdevsim/psp.c\n@@ -84,6 +84,7 @@ nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,\n \t\tstruct iphdr *iph;\n \t\tstruct udphdr *uh;\n \t\t__wsum csum;\n+\t\tint udplen;\n \n \t\t/* Do not decapsulate. Receive the skb with the udp and psp\n \t\t * headers still there as if this is a normal udp packet.\n@@ -91,19 +92,20 @@ nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,\n \t\t * provide a valid checksum here, so the skb isn't dropped.\n \t\t */\n \t\tuh = udp_hdr(skb);\n+\t\tudplen = udp_get_len(skb, uh, skb_transport_offset(skb));\n \t\tcsum = skb_checksum(skb, skb_transport_offset(skb),\n-\t\t\t\t    ntohs(uh-\u003elen), 0);\n+\t\t\t\t    udplen, 0);\n \n \t\tswitch (skb-\u003eprotocol) {\n \t\tcase htons(ETH_P_IP):\n \t\t\tiph = ip_hdr(skb);\n-\t\t\tuh-\u003echeck = udp_v4_check(ntohs(uh-\u003elen), iph-\u003esaddr,\n+\t\t\tuh-\u003echeck = udp_v4_check(udplen, iph-\u003esaddr,\n \t\t\t\t\t\t iph-\u003edaddr, csum);\n \t\t\tbreak;\n #if IS_ENABLED(CONFIG_IPV6)\n \t\tcase htons(ETH_P_IPV6):\n \t\t\tip6h = ipv6_hdr(skb);\n-\t\t\tuh-\u003echeck = udp_v6_check(ntohs(uh-\u003elen), \u0026ip6h-\u003esaddr,\n+\t\t\tuh-\u003echeck = udp_v6_check(udplen, \u0026ip6h-\u003esaddr,\n \t\t\t\t\t\t \u0026ip6h-\u003edaddr, csum);\n \t\t\tbreak;\n #endif\ndiff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c\nindex 67c367cc566233..3a32f067e701df 100644\n--- a/drivers/net/vxlan/vxlan_core.c\n+++ b/drivers/net/vxlan/vxlan_core.c\n@@ -3370,6 +3370,8 @@ static void vxlan_setup(struct net_device *dev)\n \tdev-\u003emangleid_features = NETIF_F_GSO_PARTIAL;\n \n \tnetif_keep_dst(dev);\n+\tnetif_set_tso_max_size(dev, GSO_MAX_SIZE);\n+\n \tdev-\u003epriv_flags |= IFF_NO_QUEUE;\n \tdev-\u003echange_proto_down = true;\n \tdev-\u003elltx = true;\ndiff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c\nindex eb8851113654f5..824bbefce61c78 100644\n--- a/drivers/net/wireguard/receive.c\n+++ b/drivers/net/wireguard/receive.c\n@@ -62,7 +62,7 @@ static int prepare_skb_header(struct sk_buff *skb, struct wg_device *wg)\n \t\t * to have UDP fields.\n \t\t */\n \t\treturn -EINVAL;\n-\tdata_len = ntohs(udp-\u003elen);\n+\tdata_len = udp_get_len_short(udp);\n \tif (unlikely(data_len \u003c sizeof(struct udphdr) ||\n \t\t     data_len \u003e skb-\u003elen - data_offset))\n \t\t/* UDP packet is reporting too small of a size or lying about\ndiff --git a/include/linux/udp.h b/include/linux/udp.h\nindex ce56ebcee5cbcd..998906ec3b32ad 100644\n--- a/include/linux/udp.h\n+++ b/include/linux/udp.h\n@@ -23,6 +23,33 @@ static inline struct udphdr *udp_hdr(const struct sk_buff *skb)\n \treturn (struct udphdr *)skb_transport_header(skb);\n }\n \n+static inline unsigned int udp_get_len(const struct sk_buff *skb,\n+\t\t\t\t       const struct udphdr *uh,\n+\t\t\t\t       unsigned int dataoff)\n+{\n+\tif (uh-\u003elen)\n+\t\treturn ntohs(uh-\u003elen);\n+\tif (skb_is_gso(skb)) /* BIG TCP */\n+\t\treturn skb-\u003elen - dataoff;\n+\treturn 0;\n+}\n+\n+static inline unsigned int udp_get_len_short(const struct udphdr *uh)\n+{\n+\treturn ntohs(uh-\u003elen);\n+}\n+\n+static inline void udp_set_len(struct udphdr *uh, unsigned int len)\n+{\n+\tuh-\u003elen = len \u003c GRO_LEGACY_MAX_SIZE ? htons(len) : 0;\n+}\n+\n+static inline void udp_set_len_short(struct udphdr *uh, unsigned int len)\n+{\n+\tDEBUG_NET_WARN_ON_ONCE(len \u003e= GRO_LEGACY_MAX_SIZE);\n+\tuh-\u003elen = htons(len);\n+}\n+\n #define UDP_HTABLE_SIZE_MIN_PERNET\t128\n #define UDP_HTABLE_SIZE_MIN\t\t(IS_ENABLED(CONFIG_BASE_SMALL) ? 128 : 256)\n #define UDP_HTABLE_SIZE_MAX\t\t65536\ndiff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h\nindex 31559796949a78..09ae115099dfe2 100644\n--- a/include/trace/events/icmp.h\n+++ b/include/trace/events/icmp.h\n@@ -44,7 +44,7 @@ TRACE_EVENT(icmp_send,\n \t\t\t} else {\n \t\t\t\t__entry-\u003esport = ntohs(uh-\u003esource);\n \t\t\t\t__entry-\u003edport = ntohs(uh-\u003edest);\n-\t\t\t\t__entry-\u003eulen = ntohs(uh-\u003elen);\n+\t\t\t\t__entry-\u003eulen = udp_get_len_short(uh);\n \t\t\t}\n \n \t\t\tp32 = (__be32 *) __entry-\u003esaddr;\ndiff --git a/lib/tests/blackhole_dev_kunit.c b/lib/tests/blackhole_dev_kunit.c\nindex 06834ab35f43c5..fa3e0533038d6f 100644\n--- a/lib/tests/blackhole_dev_kunit.c\n+++ b/lib/tests/blackhole_dev_kunit.c\n@@ -46,7 +46,7 @@ static void test_blackholedev(struct kunit *test)\n \tuh = (struct udphdr *)skb_push(skb, sizeof(struct udphdr));\n \tskb_set_transport_header(skb, 0);\n \tuh-\u003esource = uh-\u003edest = htons(UDP_PORT);\n-\tuh-\u003elen = htons(data_len);\n+\tudp_set_len_short(uh, data_len);\n \tuh-\u003echeck = 0;\n \t/* (Network) IPv6 */\n \tip6h = (struct ipv6hdr *)skb_push(skb, sizeof(struct ipv6hdr));\ndiff --git a/net/6lowpan/nhc_udp.c b/net/6lowpan/nhc_udp.c\nindex 0a506c77283dde..ed4227e6db7442 100644\n--- a/net/6lowpan/nhc_udp.c\n+++ b/net/6lowpan/nhc_udp.c\n@@ -88,16 +88,16 @@ static int udp_uncompress(struct sk_buff *skb, size_t needed)\n \tswitch (lowpan_dev(skb-\u003edev)-\u003elltype) {\n \tcase LOWPAN_LLTYPE_IEEE802154:\n \t\tif (lowpan_802154_cb(skb)-\u003ed_size)\n-\t\t\tuh.len = htons(lowpan_802154_cb(skb)-\u003ed_size -\n-\t\t\t\t       sizeof(struct ipv6hdr));\n+\t\t\tudp_set_len_short(\u0026uh, lowpan_802154_cb(skb)-\u003ed_size -\n+\t\t\t\t\t  sizeof(struct ipv6hdr));\n \t\telse\n-\t\t\tuh.len = htons(skb-\u003elen + sizeof(struct udphdr));\n+\t\t\tudp_set_len_short(\u0026uh, skb-\u003elen + sizeof(struct udphdr));\n \t\tbreak;\n \tdefault:\n-\t\tuh.len = htons(skb-\u003elen + sizeof(struct udphdr));\n+\t\tudp_set_len_short(\u0026uh, skb-\u003elen + sizeof(struct udphdr));\n \t\tbreak;\n \t}\n-\tpr_debug(\"uncompressed UDP length: src = %d\", ntohs(uh.len));\n+\tpr_debug(\"uncompressed UDP length: src = %d\", udp_get_len_short(\u0026uh));\n \n \t/* replace the compressed UDP head by the uncompressed UDP\n \t * header\ndiff --git a/net/core/pktgen.c b/net/core/pktgen.c\nindex 8e185b31828853..5b4dd04d612476 100644\n--- a/net/core/pktgen.c\n+++ b/net/core/pktgen.c\n@@ -3005,7 +3005,7 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,\n \n \tudph-\u003esource = htons(pkt_dev-\u003ecur_udp_src);\n \tudph-\u003edest = htons(pkt_dev-\u003ecur_udp_dst);\n-\tudph-\u003elen = htons(datalen + 8);\t/* DATA + udphdr */\n+\tudp_set_len_short(udph, datalen + 8);\t/* DATA + udphdr */\n \tudph-\u003echeck = 0;\n \n \tiph-\u003eihl = 5;\n@@ -3138,7 +3138,7 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,\n \tudplen = datalen + sizeof(struct udphdr);\n \tudph-\u003esource = htons(pkt_dev-\u003ecur_udp_src);\n \tudph-\u003edest = htons(pkt_dev-\u003ecur_udp_dst);\n-\tudph-\u003elen = htons(udplen);\n+\tudp_set_len_short(udph, udplen);\n \tudph-\u003echeck = 0;\n \n \t*(__be32 *) iph = htonl(0x60000000);\t/* Version + flow */\ndiff --git a/net/core/selftests.c b/net/core/selftests.c\nindex 0a203d3fb9dcbe..36b949ae520b31 100644\n--- a/net/core/selftests.c\n+++ b/net/core/selftests.c\n@@ -72,9 +72,9 @@ struct sk_buff *net_test_get_skb(struct net_device *ndev, u8 id,\n \t} else {\n \t\tuhdr-\u003esource = htons(attr-\u003esport);\n \t\tuhdr-\u003edest = htons(attr-\u003edport);\n-\t\tuhdr-\u003elen = htons(sizeof(*shdr) + sizeof(*uhdr) + attr-\u003esize);\n+\t\tudp_set_len_short(uhdr, sizeof(*shdr) + sizeof(*uhdr) + attr-\u003esize);\n \t\tif (attr-\u003emax_size)\n-\t\t\tuhdr-\u003elen = htons(attr-\u003emax_size -\n+\t\t\tudp_set_len_short(uhdr, attr-\u003emax_size -\n \t\t\t\t\t  (sizeof(*ihdr) + sizeof(*ehdr)));\n \t\tuhdr-\u003echeck = 0;\n \t}\ndiff --git a/net/core/skbuff.c b/net/core/skbuff.c\nindex 18dabb4e9cfa0e..6ae4c2b205f2ef 100644\n--- a/net/core/skbuff.c\n+++ b/net/core/skbuff.c\n@@ -4775,6 +4775,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,\n \tstruct sk_buff *tail = NULL;\n \tstruct sk_buff *list_skb = skb_shinfo(head_skb)-\u003efrag_list;\n \tunsigned int mss = skb_shinfo(head_skb)-\u003egso_size;\n+\tbool gso_by_frags = mss == GSO_BY_FRAGS;\n \tunsigned int doffset = head_skb-\u003edata - skb_mac_header(head_skb);\n \tunsigned int offset = doffset;\n \tunsigned int tnl_hlen = skb_tnl_header_len(head_skb);\n@@ -4790,7 +4791,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,\n \tint nfrags, pos;\n \n \tif ((skb_shinfo(head_skb)-\u003egso_type \u0026 SKB_GSO_DODGY) \u0026\u0026\n-\t    mss != GSO_BY_FRAGS \u0026\u0026 mss != skb_headlen(head_skb)) {\n+\t    !gso_by_frags \u0026\u0026 mss != skb_headlen(head_skb)) {\n \t\tstruct sk_buff *check_skb;\n \n \t\tfor (check_skb = list_skb; check_skb; check_skb = check_skb-\u003enext) {\n@@ -4818,7 +4819,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,\n \tsg = !!(features \u0026 NETIF_F_SG);\n \tcsum = !!can_checksum_protocol(features, proto);\n \n-\tif (sg \u0026\u0026 csum \u0026\u0026 (mss != GSO_BY_FRAGS))  {\n+\tif (sg \u0026\u0026 csum \u0026\u0026 !gso_by_frags)  {\n \t\tif (!(features \u0026 NETIF_F_GSO_PARTIAL)) {\n \t\t\tstruct sk_buff *iter;\n \t\t\tunsigned int frag_len;\n@@ -4852,9 +4853,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,\n \t\t/* GSO partial only requires that we trim off any excess that\n \t\t * doesn't fit into an MSS sized block, so take care of that\n \t\t * now.\n-\t\t * Cap len to not accidentally hit GSO_BY_FRAGS.\n \t\t */\n-\t\tpartial_segs = min(len, GSO_BY_FRAGS - 1) / mss;\n+\t\tpartial_segs = len / mss;\n \t\tif (partial_segs \u003e 1)\n \t\t\tmss *= partial_segs;\n \t\telse\n@@ -4878,7 +4878,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,\n \t\tint hsize;\n \t\tint size;\n \n-\t\tif (unlikely(mss == GSO_BY_FRAGS)) {\n+\t\tif (unlikely(gso_by_frags)) {\n \t\t\tlen = list_skb-\u003elen;\n \t\t} else {\n \t\t\tlen = head_skb-\u003elen - offset;\ndiff --git a/net/core/tso.c b/net/core/tso.c\nindex 347b3856ddb91f..d2934bcfa795f0 100644\n--- a/net/core/tso.c\n+++ b/net/core/tso.c\n@@ -39,7 +39,8 @@ void tso_build_hdr(const struct sk_buff *skb, char *hdr, struct tso_t *tso,\n \t} else {\n \t\tstruct udphdr *uh = (struct udphdr *)hdr;\n \n-\t\tuh-\u003elen = htons(sizeof(*uh) + size);\n+\t\t/* size is after segmentation. */\n+\t\tudp_set_len_short(uh, sizeof(*uh) + size);\n \t}\n }\n EXPORT_SYMBOL(tso_build_hdr);\ndiff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c\nindex dfc81ee969ae03..a6c18aea7498d8 100644\n--- a/net/ipv4/esp4.c\n+++ b/net/ipv4/esp4.c\n@@ -323,7 +323,7 @@ static struct ip_esp_hdr *esp_output_udp_encap(struct sk_buff *skb,\n \tuh = (struct udphdr *)esp-\u003eesph;\n \tuh-\u003esource = sport;\n \tuh-\u003edest = dport;\n-\tuh-\u003elen = htons(len);\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \t/* For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload\ndiff --git a/net/ipv4/fou_core.c b/net/ipv4/fou_core.c\nindex 865bd7205122d2..aef3ce1dec7aa2 100644\n--- a/net/ipv4/fou_core.c\n+++ b/net/ipv4/fou_core.c\n@@ -1040,7 +1040,7 @@ static void fou_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,\n \n \tuh-\u003edest = e-\u003edport;\n \tuh-\u003esource = sport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \tudp_set_csum(!(e-\u003eflags \u0026 TUNNEL_ENCAP_FLAG_CSUM), skb,\n \t\t     fl4-\u003esaddr, fl4-\u003edaddr, skb-\u003elen);\n \ndiff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c\nindex a35ffedacc7c7f..155db067eaecbe 100644\n--- a/net/ipv4/ipconfig.c\n+++ b/net/ipv4/ipconfig.c\n@@ -847,7 +847,7 @@ static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies_d\n \t/* Construct UDP header */\n \tb-\u003eudph.source = htons(68);\n \tb-\u003eudph.dest = htons(67);\n-\tb-\u003eudph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr));\n+\tudp_set_len_short(\u0026b-\u003eudph, sizeof(struct bootp_pkt) - sizeof(struct iphdr));\n \t/* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */\n \n \t/* Construct DHCP/BOOTP header */\n@@ -1025,10 +1025,10 @@ static int __init ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, str\n \tif (b-\u003eudph.source != htons(67) || b-\u003eudph.dest != htons(68))\n \t\tgoto drop;\n \n-\tif (ntohs(h-\u003etot_len) \u003c ntohs(b-\u003eudph.len) + sizeof(struct iphdr))\n+\tif (ntohs(h-\u003etot_len) \u003c udp_get_len_short(\u0026b-\u003eudph) + sizeof(struct iphdr))\n \t\tgoto drop;\n \n-\tlen = ntohs(b-\u003eudph.len) - sizeof(struct udphdr);\n+\tlen = udp_get_len_short(\u0026b-\u003eudph) - sizeof(struct udphdr);\n \text_len = len - (sizeof(*b) -\n \t\t\t sizeof(struct iphdr) -\n \t\t\t sizeof(struct udphdr) -\ndiff --git a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\nindex e540b86bd15b6b..4492bc548a66bf 100644\n--- a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\n+++ b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c\n@@ -127,7 +127,7 @@ static int snmp_translate(struct nf_conn *ct, int dir, struct sk_buff *skb)\n {\n \tstruct iphdr *iph = ip_hdr(skb);\n \tstruct udphdr *udph = (struct udphdr *)((__be32 *)iph + iph-\u003eihl);\n-\tu16 datalen = ntohs(udph-\u003elen) - sizeof(struct udphdr);\n+\tu16 datalen = udp_get_len_short(udph) - sizeof(struct udphdr);\n \tchar *data = (unsigned char *)udph + sizeof(struct udphdr);\n \tstruct snmp_ctx ctx;\n \tint ret;\n@@ -181,7 +181,7 @@ static int help(struct sk_buff *skb, unsigned int protoff,\n \t * enough room for a UDP header.  Just verify the UDP length field so we\n \t * can mess around with the payload.\n \t */\n-\tif (ntohs(udph-\u003elen) != skb-\u003elen - (iph-\u003eihl \u003c\u003c 2)) {\n+\tif (udp_get_len_short(udph) != skb-\u003elen - (iph-\u003eihl \u003c\u003c 2)) {\n \t\tnf_ct_helper_log(skb, ct, \"dropping malformed packet\\n\");\n \t\treturn NF_DROP;\n \t}\ndiff --git a/net/ipv4/route.c b/net/ipv4/route.c\nindex 3f3de5164d6e58..0825ed9837146c 100644\n--- a/net/ipv4/route.c\n+++ b/net/ipv4/route.c\n@@ -3187,7 +3187,7 @@ static struct sk_buff *inet_rtm_getroute_build_skb(__be32 src, __be32 dst,\n \t\tudph = skb_put_zero(skb, sizeof(struct udphdr));\n \t\tudph-\u003esource = sport;\n \t\tudph-\u003edest = dport;\n-\t\tudph-\u003elen = htons(sizeof(struct udphdr));\n+\t\tudp_set_len_short(udph, sizeof(struct udphdr));\n \t\tudph-\u003echeck = 0;\n \t\tbreak;\n \t}\ndiff --git a/net/ipv4/udp.c b/net/ipv4/udp.c\nindex 59248a59358ca5..2b9b55a147582b 100644\n--- a/net/ipv4/udp.c\n+++ b/net/ipv4/udp.c\n@@ -1108,7 +1108,8 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,\n \tuh = udp_hdr(skb);\n \tuh-\u003esource = inet_sk(sk)-\u003einet_sport;\n \tuh-\u003edest = fl4-\u003efl4_dport;\n-\tuh-\u003elen = htons(len);\n+\t/* Datagram length checked in udp_sendmsg. */\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \tif (cork-\u003egso_size) {\n@@ -2591,8 +2592,8 @@ int udp_rcv(struct sk_buff *skb)\n \tstruct rtable *rt = skb_rtable(skb);\n \tstruct net *net = dev_net(skb-\u003edev);\n \tstruct sock *sk = NULL;\n-\tunsigned short ulen;\n \t__be32 saddr, daddr;\n+\tunsigned int ulen;\n \tstruct udphdr *uh;\n \tbool refcounted;\n \tint drop_reason;\n@@ -2606,7 +2607,7 @@ int udp_rcv(struct sk_buff *skb)\n \t\tgoto drop;\t\t/* No space for header. */\n \n \tuh   = udp_hdr(skb);\n-\tulen = ntohs(uh-\u003elen);\n+\tulen = udp_get_len(skb, uh, 0);\n \tsaddr = ip_hdr(skb)-\u003esaddr;\n \tdaddr = ip_hdr(skb)-\u003edaddr;\n \ndiff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c\nindex 29651b1a0bc704..8f77c8788f6db0 100644\n--- a/net/ipv4/udp_offload.c\n+++ b/net/ipv4/udp_offload.c\n@@ -279,11 +279,11 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,\n \t\t * segment instead of the entire frame.\n \t\t */\n \t\tif (gso_partial \u0026\u0026 skb_is_gso(skb)) {\n-\t\t\tuh-\u003elen = htons(skb_shinfo(skb)-\u003egso_size +\n-\t\t\t\t\tSKB_GSO_CB(skb)-\u003edata_offset +\n-\t\t\t\t\tskb-\u003ehead - (unsigned char *)uh);\n+\t\t\tudp_set_len_short(uh, skb_shinfo(skb)-\u003egso_size +\n+\t\t\t\t\t  SKB_GSO_CB(skb)-\u003edata_offset +\n+\t\t\t\t\t  skb-\u003ehead - (unsigned char *)uh);\n \t\t} else {\n-\t\t\tuh-\u003elen = htons(len);\n+\t\t\tudp_set_len_short(uh, len);\n \t\t}\n \n \t\tif (!need_csum)\n@@ -468,7 +468,7 @@ static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,\n \tif (IS_ERR(skb))\n \t\treturn skb;\n \n-\tudp_hdr(skb)-\u003elen = htons(sizeof(struct udphdr) + mss);\n+\tudp_set_len_short(udp_hdr(skb), sizeof(struct udphdr) + mss);\n \n \tif (is_ipv6)\n \t\treturn __udpv6_gso_segment_list_csum(skb);\n@@ -486,8 +486,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,\n \tunsigned int mss;\n \tbool copy_dtor;\n \t__sum16 check;\n-\t__be16 newlen;\n \tint ret = 0;\n+\tu16 newlen;\n \n \tmss = skb_shinfo(gso_skb)-\u003egso_size;\n \tif (gso_skb-\u003elen \u003c= sizeof(*uh) + mss)\n@@ -564,8 +564,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,\n \t\t\t(skb_shinfo(gso_skb)-\u003etx_flags \u0026 SKBTX_ANY_TSTAMP);\n \n \t/* compute checksum adjustment based on old length versus new */\n-\tnewlen = htons(sizeof(*uh) + mss);\n-\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), newlen);\n+\tnewlen = sizeof(*uh) + mss;\n+\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), htons(newlen));\n \n \tfor (;;) {\n \t\tif (copy_dtor) {\n@@ -577,7 +577,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,\n \t\tif (!seg-\u003enext)\n \t\t\tbreak;\n \n-\t\tuh-\u003elen = newlen;\n+\t\tudp_set_len_short(uh, newlen);\n \t\tuh-\u003echeck = check;\n \n \t\tif (seg-\u003eip_summed == CHECKSUM_PARTIAL)\n@@ -594,11 +594,10 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,\n \t * segment may not be full MSS, account for that in the checksum\n \t */\n \tif (!skb_is_gso(seg))\n-\t\tnewlen = htons(skb_tail_pointer(seg) -\n-\t\t\t       skb_transport_header(seg) + seg-\u003edata_len);\n-\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), newlen);\n+\t\tnewlen = skb_tail_pointer(seg) - skb_transport_header(seg) + seg-\u003edata_len;\n+\tcheck = csum16_add(csum16_sub(uh-\u003echeck, uh-\u003elen), htons(newlen));\n \n-\tuh-\u003elen = newlen;\n+\tudp_set_len_short(uh, newlen);\n \tuh-\u003echeck = check;\n \n \tif (seg-\u003eip_summed == CHECKSUM_PARTIAL)\n@@ -708,12 +707,8 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,\n \t\treturn NULL;\n \t}\n \n-\t/* Do not deal with padded or malicious packets, sorry ! */\n-\tulen = ntohs(uh-\u003elen);\n-\tif (ulen \u003c= sizeof(*uh) || ulen != skb_gro_len(skb)) {\n-\t\tNAPI_GRO_CB(skb)-\u003eflush = 1;\n-\t\treturn NULL;\n-\t}\n+\tulen = udp_get_len_short(uh);\n+\n \t/* pull encapsulating udp header */\n \tskb_gro_pull(skb, sizeof(struct udphdr));\n \n@@ -742,7 +737,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,\n \t\t * On len mismatch merge the first packet shorter than gso_size,\n \t\t * otherwise complete the GRO packet.\n \t\t */\n-\t\tif (ulen \u003e ntohs(uh2-\u003elen) || flush) {\n+\t\tif (ulen \u003e udp_get_len_short(uh2) || flush) {\n \t\t\tpp = p;\n \t\t} else {\n \t\t\tif (NAPI_GRO_CB(skb)-\u003eis_flist) {\n@@ -765,7 +760,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,\n \t\t\t}\n \t\t}\n \n-\t\tif (ret || ulen != ntohs(uh2-\u003elen) ||\n+\t\tif (ret || ulen != udp_get_len_short(uh2) ||\n \t\t    NAPI_GRO_CB(p)-\u003ecount \u003e= UDP_GRO_CNT_MAX)\n \t\t\tpp = p;\n \n@@ -783,8 +778,14 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,\n \tstruct sk_buff *p;\n \tstruct udphdr *uh2;\n \tunsigned int off = skb_gro_offset(skb);\n+\tunsigned int ulen;\n \tint flush = 1;\n \n+\t/* Do not deal with padded or malicious packets, sorry! */\n+\tulen = udp_get_len_short(uh);\n+\tif (ulen \u003c= sizeof(*uh) || ulen != skb_gro_len(skb))\n+\t\tgoto out;\n+\n \t/* We can do L4 aggregation only if the packet can't land in a tunnel\n \t * otherwise we could corrupt the inner stream. Detecting such packets\n \t * cannot be foolproof and the aggregation might still happen in some\n@@ -915,12 +916,12 @@ static int udp_gro_complete_segment(struct sk_buff *skb)\n int udp_gro_complete(struct sk_buff *skb, int nhoff,\n \t\t     udp_lookup_t lookup)\n {\n-\t__be16 newlen = htons(skb-\u003elen - nhoff);\n \tstruct udphdr *uh = (struct udphdr *)(skb-\u003edata + nhoff);\n+\tunsigned int newlen = skb-\u003elen - nhoff;\n \tstruct sock *sk;\n \tint err;\n \n-\tuh-\u003elen = newlen;\n+\tudp_set_len(uh, newlen);\n \n \tsk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,\n \t\t\t\tudp4_lib_lookup_skb, skb, uh-\u003esource, uh-\u003edest);\n@@ -957,7 +958,7 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)\n \n \t/* do fraglist only if there is no outer UDP encap (or we already processed it) */\n \tif (NAPI_GRO_CB(skb)-\u003eis_flist \u0026\u0026 !NAPI_GRO_CB(skb)-\u003eencap_mark) {\n-\t\tuh-\u003elen = htons(skb-\u003elen - nhoff);\n+\t\tudp_set_len(uh, skb-\u003elen - nhoff);\n \n \t\tskb_shinfo(skb)-\u003egso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);\n \t\tskb_shinfo(skb)-\u003egso_segs = NAPI_GRO_CB(skb)-\u003ecount;\ndiff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c\nindex 9ab3728f9630bf..a128fe85620d30 100644\n--- a/net/ipv4/udp_tunnel_core.c\n+++ b/net/ipv4/udp_tunnel_core.c\n@@ -178,7 +178,7 @@ void udp_tunnel_xmit_skb(struct rtable *rt, struct sock *sk, struct sk_buff *skb\n \n \tuh-\u003edest = dst_port;\n \tuh-\u003esource = src_port;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \n \tmemset(\u0026(IPCB(skb)-\u003eopt), 0, sizeof(IPCB(skb)-\u003eopt));\n \ndiff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c\nindex 296b57926abb98..72ec0d7d112090 100644\n--- a/net/ipv6/esp6.c\n+++ b/net/ipv6/esp6.c\n@@ -230,7 +230,8 @@ static void esp_output_encap_csum(struct sk_buff *skb)\n \tif (*skb_mac_header(skb) == IPPROTO_UDP) {\n \t\tstruct udphdr *uh = udp_hdr(skb);\n \t\tstruct ipv6hdr *ip6h = ipv6_hdr(skb);\n-\t\tint len = ntohs(uh-\u003elen);\n+\t\t/* esp6_output_udp_encap limits len to U16_MAX. */\n+\t\tint len = udp_get_len_short(uh);\n \t\tunsigned int offset = skb_transport_offset(skb);\n \t\t__wsum csum = skb_checksum(skb, offset, skb-\u003elen - offset, 0);\n \n@@ -358,7 +359,7 @@ static struct ip_esp_hdr *esp6_output_udp_encap(struct sk_buff *skb,\n \tuh = (struct udphdr *)esp-\u003eesph;\n \tuh-\u003esource = sport;\n \tuh-\u003edest = dport;\n-\tuh-\u003elen = htons(len);\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \t*skb_mac_header(skb) = IPPROTO_UDP;\ndiff --git a/net/ipv6/fou6.c b/net/ipv6/fou6.c\nindex 157765259e2f5f..4b659ca60ba9a8 100644\n--- a/net/ipv6/fou6.c\n+++ b/net/ipv6/fou6.c\n@@ -30,7 +30,7 @@ static void fou6_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,\n \n \tuh-\u003edest = e-\u003edport;\n \tuh-\u003esource = sport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \tudp6_set_csum(!(e-\u003eflags \u0026 TUNNEL_ENCAP_FLAG_CSUM6), skb,\n \t\t      \u0026fl6-\u003esaddr, \u0026fl6-\u003edaddr, skb-\u003elen);\n \ndiff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c\nindex 9adb5775487fac..32525a051a6f08 100644\n--- a/net/ipv6/ip6_udp_tunnel.c\n+++ b/net/ipv6/ip6_udp_tunnel.c\n@@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,\n \tuh-\u003edest = dst_port;\n \tuh-\u003esource = src_port;\n \n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(uh, skb-\u003elen);\n \n \tskb_dst_set(skb, dst);\n \ndiff --git a/net/ipv6/udp.c b/net/ipv6/udp.c\nindex 392e18b9704544..02272466f4c298 100644\n--- a/net/ipv6/udp.c\n+++ b/net/ipv6/udp.c\n@@ -1081,12 +1081,12 @@ INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)\n \tdaddr = \u0026ipv6_hdr(skb)-\u003edaddr;\n \tuh = udp_hdr(skb);\n \n-\tulen = ntohs(uh-\u003elen);\n+\tulen = udp_get_len(skb, uh, 0);\n \tif (ulen \u003e skb-\u003elen)\n \t\tgoto short_packet;\n \n \t/* Check for jumbo payload */\n-\tif (ulen == 0)\n+\tif (ulen == 0 \u0026\u0026 inet6_is_jumbogram(skb))\n \t\tulen = skb-\u003elen;\n \n \tif (ulen \u003c sizeof(*uh))\n@@ -1369,7 +1369,8 @@ static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,\n \tuh = udp_hdr(skb);\n \tuh-\u003esource = fl6-\u003efl6_sport;\n \tuh-\u003edest = fl6-\u003efl6_dport;\n-\tuh-\u003elen = htons(len);\n+\t/* Datagram length checked in udpv6_sendmsg. */\n+\tudp_set_len_short(uh, len);\n \tuh-\u003echeck = 0;\n \n \tif (cork-\u003egso_size) {\ndiff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c\nindex 778afc7453ce53..7370bcb80332ea 100644\n--- a/net/ipv6/udp_offload.c\n+++ b/net/ipv6/udp_offload.c\n@@ -171,7 +171,7 @@ int udp6_gro_complete(struct sk_buff *skb, int nhoff)\n \n \t/* do fraglist only if there is no outer UDP encap (or we already processed it) */\n \tif (NAPI_GRO_CB(skb)-\u003eis_flist \u0026\u0026 !NAPI_GRO_CB(skb)-\u003eencap_mark) {\n-\t\tuh-\u003elen = htons(skb-\u003elen - nhoff);\n+\t\tudp_set_len(uh, skb-\u003elen - nhoff);\n \n \t\tskb_shinfo(skb)-\u003egso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);\n \t\tskb_shinfo(skb)-\u003egso_segs = NAPI_GRO_CB(skb)-\u003ecount;\ndiff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c\nindex f940914959b18e..4712cc41881a30 100644\n--- a/net/l2tp/l2tp_core.c\n+++ b/net/l2tp/l2tp_core.c\n@@ -1296,7 +1296,7 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, uns\n \t\t\tret = NET_XMIT_DROP;\n \t\t\tgoto out_unlock;\n \t\t}\n-\t\tuh-\u003elen = htons(udp_len);\n+\t\tudp_set_len_short(uh, udp_len);\n \n \t\t/* Calculate UDP checksum if configured to do so */\n #if IS_ENABLED(CONFIG_IPV6)\ndiff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c\nindex ce542ed4b013c8..c51ebd83a476fe 100644\n--- a/net/netfilter/ipvs/ip_vs_xmit.c\n+++ b/net/netfilter/ipvs/ip_vs_xmit.c\n@@ -1100,7 +1100,7 @@ ipvs_gue_encap(struct net *net, struct sk_buff *skb,\n \tdport = cp-\u003edest-\u003etun_port;\n \tudph-\u003edest = dport;\n \tudph-\u003esource = sport;\n-\tudph-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len(udph, skb-\u003elen);\n \tudph-\u003echeck = 0;\n \n \t*next_protocol = IPPROTO_UDP;\ndiff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c\nindex cc9b7e5e19358d..a7edfefd6fd14b 100644\n--- a/net/netfilter/nf_conntrack_proto_udp.c\n+++ b/net/netfilter/nf_conntrack_proto_udp.c\n@@ -41,11 +41,22 @@ static void udp_error_log(const struct sk_buff *skb,\n \tnf_l4proto_log_invalid(skb, state, IPPROTO_UDP, \"%s\", msg);\n }\n \n+static bool udp_validate_len(struct sk_buff *skb,\n+\t\t\t     const struct udphdr *hdr,\n+\t\t\t     unsigned int dataoff)\n+{\n+\tunsigned int udplen = udp_get_len(skb, hdr, dataoff);\n+\tunsigned int skblen = skb-\u003elen - dataoff;\n+\n+\tif (udplen \u003e skblen || udplen \u003c sizeof(*hdr))\n+\t\treturn false;\n+\treturn true;\n+}\n+\n static bool udp_error(struct sk_buff *skb,\n \t\t      unsigned int dataoff,\n \t\t      const struct nf_hook_state *state)\n {\n-\tunsigned int udplen = skb-\u003elen - dataoff;\n \tconst struct udphdr *hdr;\n \tstruct udphdr _hdr;\n \n@@ -57,7 +68,7 @@ static bool udp_error(struct sk_buff *skb,\n \t}\n \n \t/* Truncated/malformed packets */\n-\tif (ntohs(hdr-\u003elen) \u003e udplen || ntohs(hdr-\u003elen) \u003c sizeof(*hdr)) {\n+\tif (!udp_validate_len(skb, hdr, dataoff)) {\n \t\tudp_error_log(skb, state, \"truncated/malformed packet\");\n \t\treturn true;\n \t}\ndiff --git a/net/netfilter/nf_log_syslog.c b/net/netfilter/nf_log_syslog.c\nindex e37b09b3203b75..71dff0eb672c43 100644\n--- a/net/netfilter/nf_log_syslog.c\n+++ b/net/netfilter/nf_log_syslog.c\n@@ -301,7 +301,7 @@ nf_log_dump_udp_header(struct nf_log_buf *m,\n \n \t/* Max length: 20 \"SPT=65535 DPT=65535 \" */\n \tnf_log_buf_add(m, \"SPT=%u DPT=%u LEN=%u \",\n-\t\t       ntohs(uh-\u003esource), ntohs(uh-\u003edest), ntohs(uh-\u003elen));\n+\t\t       ntohs(uh-\u003esource), ntohs(uh-\u003edest), udp_get_len_short(uh));\n \n out:\n \treturn 0;\ndiff --git a/net/netfilter/nf_nat_helper.c b/net/netfilter/nf_nat_helper.c\nindex bf591e6af0051a..3853f41db49953 100644\n--- a/net/netfilter/nf_nat_helper.c\n+++ b/net/netfilter/nf_nat_helper.c\n@@ -161,7 +161,7 @@ nf_nat_mangle_udp_packet(struct sk_buff *skb,\n \n \t/* update the length of the UDP packet */\n \tdatalen = skb-\u003elen - protoff;\n-\tudph-\u003elen = htons(datalen);\n+\tudp_set_len_short(udph, datalen);\n \n \t/* fix udp checksum if udp checksum was previously calculated */\n \tif (!udph-\u003echeck \u0026\u0026 skb-\u003eip_summed != CHECKSUM_PARTIAL)\ndiff --git a/net/psp/psp_main.c b/net/psp/psp_main.c\nindex 8b2f178e317cb8..c9c1a8826b7f92 100644\n--- a/net/psp/psp_main.c\n+++ b/net/psp/psp_main.c\n@@ -231,7 +231,7 @@ static void psp_write_headers(struct net *net, struct sk_buff *skb, __be32 spi,\n \t\tuh-\u003esource = udp_flow_src_port(net, skb, 0, 0, false);\n \t}\n \tuh-\u003echeck = 0;\n-\tuh-\u003elen = htons(udp_len);\n+\tudp_set_len(uh, udp_len);\n \n \tpsph-\u003enexthdr = IPPROTO_TCP;\n \tpsph-\u003ehdrlen = PSP_HDRLEN_NOOPT;\ndiff --git a/net/sched/act_csum.c b/net/sched/act_csum.c\nindex 078d3a27130b8d..5fff52a8ca90dc 100644\n--- a/net/sched/act_csum.c\n+++ b/net/sched/act_csum.c\n@@ -276,7 +276,7 @@ static int tcf_csum_ipv4_udp(struct sk_buff *skb, unsigned int ihl,\n \t\treturn 0;\n \n \tiph = ip_hdr(skb);\n-\tul = ntohs(udph-\u003elen);\n+\tul = udp_get_len_short(udph);\n \n \tif (udplite || udph-\u003echeck) {\n \n@@ -334,7 +334,7 @@ static int tcf_csum_ipv6_udp(struct sk_buff *skb, unsigned int ihl,\n \t\treturn 0;\n \n \tip6h = ipv6_hdr(skb);\n-\tul = ntohs(udph-\u003elen);\n+\tul = udp_get_len_short(udph);\n \n \tudph-\u003echeck = 0;\n \ndiff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c\nindex 458931062a04ef..906458f3d8c525 100644\n--- a/net/xfrm/xfrm_nat_keepalive.c\n+++ b/net/xfrm/xfrm_nat_keepalive.c\n@@ -133,7 +133,7 @@ static void nat_keepalive_send(struct nat_keepalive *ka)\n \tuh = skb_push(skb, sizeof(*uh));\n \tuh-\u003esource = ka-\u003eencap_sport;\n \tuh-\u003edest = ka-\u003eencap_dport;\n-\tuh-\u003elen = htons(skb-\u003elen);\n+\tudp_set_len_short(uh, skb-\u003elen);\n \tuh-\u003echeck = 0;\n \n \tskb-\u003emark = ka-\u003esmark;\ndiff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile\nindex 708d960ae07d5b..4cb0a0bc1eeace 100644\n--- a/tools/testing/selftests/net/Makefile\n+++ b/tools/testing/selftests/net/Makefile\n@@ -13,6 +13,7 @@ TEST_PROGS := \\\n \tarp_ndisc_untracked_subnets.sh \\\n \tbareudp.sh \\\n \tbig_tcp.sh \\\n+\tbig_tcp_tunnels.sh \\\n \tbind_bhash.sh \\\n \tbpf_offload.py \\\n \tbridge_stp_mode.sh \\\ndiff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh\nnew file mode 100755\nindex 00000000000000..128a710e74ad5a\n--- /dev/null\n+++ b/tools/testing/selftests/net/big_tcp_tunnels.sh\n@@ -0,0 +1,183 @@\n+#!/usr/bin/env bash\n+# SPDX-License-Identifier: GPL-2.0\n+#\n+# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.\n+\n+SERVER_NS=$(mktemp -u server-XXXXXXXX)\n+SERVER_IP4=\"192.168.1.1\"\n+SERVER_IP6=\"2001:db8::1:1\"\n+SERVER_IP4_TUN=\"192.168.2.1\"\n+SERVER_IP6_TUN=\"2001:db8::2:1\"\n+\n+CLIENT_NS=$(mktemp -u client-XXXXXXXX)\n+CLIENT_IP4=\"192.168.1.2\"\n+CLIENT_IP6=\"2001:db8::1:2\"\n+CLIENT_IP4_TUN=\"192.168.2.2\"\n+CLIENT_IP6_TUN=\"2001:db8::2:2\"\n+\n+: \"${PACKETS_THRESHOLD:=1000}\"\n+\n+# Kselftest framework requirement - SKIP code is 4.\n+ksft_skip=4\n+\n+setup() {\n+\tip netns add \"$SERVER_NS\"\n+\tip netns add \"$CLIENT_NS\"\n+\tip -netns \"$SERVER_NS\" link add link1 type veth peer name link0 netns \"$CLIENT_NS\"\n+\n+\tip -netns \"$CLIENT_NS\" link set link0 up\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP4/24\" dev link0\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP6/112\" dev link0 nodad\n+\tip -netns \"$CLIENT_NS\" link set link0 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\tip -netns \"$SERVER_NS\" link set link1 up\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP4/24\" dev link1\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP6/112\" dev link1 nodad\n+\tip -netns \"$SERVER_NS\" link set link1 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\n+\tip netns exec \"$SERVER_NS\" netserver \u003e/dev/null\n+}\n+\n+setup_tunnel() {\n+\tif [ \"$2\" = 4 ]; then\n+\t\tSERVER_IP=\"$SERVER_IP4\"\n+\t\tCLIENT_IP=\"$CLIENT_IP4\"\n+\t\techo \"Setting up ${1^^} over IPv4, veth tx csum offload $3\"\n+\telse\n+\t\tSERVER_IP=\"$SERVER_IP6\"\n+\t\tCLIENT_IP=\"$CLIENT_IP6\"\n+\t\techo \"Setting up ${1^^} over IPv6, veth tx csum offload $3\"\n+\tfi\n+\n+\tif [ \"$1\" = vxlan ]; then\n+\t\tip -netns \"$CLIENT_NS\" link add tun0 type vxlan \\\n+\t\t\tid 5001 remote \"$SERVER_IP\" local \"$CLIENT_IP\" dev link0 dstport 4789\n+\telse\n+\t\tip -netns \"$CLIENT_NS\" link add tun0 type geneve \\\n+\t\t\tid 5001 remote \"$SERVER_IP\"\n+\tfi\n+\tip -netns \"$CLIENT_NS\" link set tun0 up\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP4_TUN/24\" dev tun0\n+\tip -netns \"$CLIENT_NS\" addr replace \"$CLIENT_IP6_TUN/112\" dev tun0 nodad\n+\tip -netns \"$CLIENT_NS\" link set tun0 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\tif [ \"$1\" = vxlan ]; then\n+\t\tip -netns \"$SERVER_NS\" link add tun1 type vxlan \\\n+\t\t\tid 5001 remote \"$CLIENT_IP\" local \"$SERVER_IP\" dev link1 dstport 4789\n+\telse\n+\t\tip -netns \"$SERVER_NS\" link add tun1 type geneve \\\n+\t\t\tid 5001 remote \"$CLIENT_IP\"\n+\tfi\n+\tip -netns \"$SERVER_NS\" link set tun1 up\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP4_TUN/24\" dev tun1\n+\tip -netns \"$SERVER_NS\" addr replace \"$SERVER_IP6_TUN/112\" dev tun1 nodad\n+\tip -netns \"$SERVER_NS\" link set tun1 \\\n+\t\tgso_max_size 196608 gso_ipv4_max_size 196608 \\\n+\t\tgro_max_size 196608 gro_ipv4_max_size 196608\n+\n+\tip netns exec \"$CLIENT_NS\" ethtool -K link0 tx-checksumming \"$3\" \u003e /dev/null\n+\tip netns exec \"$SERVER_NS\" ethtool -K link1 tx-checksumming \"$3\" \u003e /dev/null\n+}\n+\n+cleanup_tunnel() {\n+\tip -netns \"$CLIENT_NS\" link del tun0\n+\tip -netns \"$SERVER_NS\" link del tun1\n+}\n+\n+cleanup() {\n+\tip netns pids \"$SERVER_NS\" | xargs -r kill\n+\tip netns pids \"$CLIENT_NS\" | xargs -r kill\n+\tip netns del \"$SERVER_NS\"\n+\tip netns del \"$CLIENT_NS\"\n+\trm -rf \"$WORKDIR\"\n+}\n+\n+do_test() {\n+\t# When tx csum offload is off, software GSO is performed before passing the\n+\t# packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify\n+\t# the software checksum path: if the checksum code is broken, these packets\n+\t# will be dropped.\n+\tif [ \"$2\" = on ]; then\n+\t\tCAPTURE_IFACE='link'\n+\telse\n+\t\tCAPTURE_IFACE='tun'\n+\tfi\n+\n+\tip netns exec \"$SERVER_NS\" tcpdump -nn -s 256 -i \"${CAPTURE_IFACE}1\" greater 65536 -w \"$WORKDIR/server.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_SERVER_PID=\"$!\"\n+\tip netns exec \"$CLIENT_NS\" tcpdump -nn -s 256 -i \"${CAPTURE_IFACE}0\" greater 65536 -w \"$WORKDIR/client.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_CLIENT_PID=\"$!\"\n+\n+\t# This filter doesn't capture all possible variants of SACK, but it's aimed\n+\t# at the typical one where SACK follows after [nop, nop, timestamp, nop,\n+\t# nop] (14 bytes after the 20-byte TCP header). IPv6 needs a separate match,\n+\t# because man tcpdump says:\n+\t# \u003e Arithmetic expression against transport layer headers, like tcp[0], does\n+\t# \u003e not work against IPv6 packets.  It only looks at IPv4 packets.\n+\tip netns exec \"$SERVER_NS\" tcpdump -nn -s 256 -i \"tun1\" '(tcp[tcpflags] \u0026 (tcp-syn|tcp-ack) = tcp-ack and tcp[34:2] \u0026 0xffc3 = 0x0502) or (ip6[6] = 0x06 and ip6[53] \u0026 0x12 = 0x10 and ip6[74:2] \u0026 0xffc3 = 0x0502)' -w \"$WORKDIR/sack.pcap\" 2\u003e /dev/null \u0026\n+\tTCPDUMP_SACK_PID=\"$!\"\n+\n+\tif [ \"$1\" = 4 ]; then\n+\t\tSERVER_IP=\"$SERVER_IP4_TUN\"\n+\t\techo \"Running IPv4 traffic in the tunnel\"\n+\telse\n+\t\tSERVER_IP=\"$SERVER_IP6_TUN\"\n+\t\techo \"Running IPv6 traffic in the tunnel\"\n+\tfi\n+\n+\tsleep 1 # Give tcpdump a second to spin up.\n+\tip netns exec \"$CLIENT_NS\" netperf -t TCP_STREAM -l 5 -H \"$SERVER_IP\" -- \\\n+\t\t-m 80000 \u003e /dev/null\n+\tsleep 1 # Give tcpdump a second to process buffered packets.\n+\tkill \"$TCPDUMP_SERVER_PID\" \"$TCPDUMP_CLIENT_PID\" \"$TCPDUMP_SACK_PID\"\n+\twait \"$TCPDUMP_SERVER_PID\" \"$TCPDUMP_CLIENT_PID\" \"$TCPDUMP_SACK_PID\"\n+\tPACKETS_SERVER=$(tcpdump --count -r \"$WORKDIR/server.pcap\" 2\u003e /dev/null | cut -d ' ' -f 1)\n+\tPACKETS_CLIENT=$(tcpdump --count -r \"$WORKDIR/client.pcap\" 2\u003e /dev/null | cut -d ' ' -f 1)\n+\tPACKETS_SACK=$(tcpdump --count -r \"$WORKDIR/sack.pcap\" 2\u003e /dev/null | cut -d ' ' -f 1)\n+\n+\techo \"Captured BIG TCP RX packets: $PACKETS_SERVER\"\n+\techo \"Captured BIG TCP TX packets: $PACKETS_CLIENT\"\n+\techo \"Captured TCP SACK packets: $PACKETS_SACK\"\n+\t[ \"$PACKETS_SERVER\" -gt \"$PACKETS_THRESHOLD\" ] || return 1\n+\t[ \"$PACKETS_CLIENT\" -gt \"$PACKETS_THRESHOLD\" ] || return 1\n+\t[ \"$PACKETS_SACK\" -lt \"$(( PACKETS_CLIENT / 2 ))\" ] || return 1\n+}\n+\n+if ! netperf -V \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without netperf tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! tcpdump --version \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without tcpdump tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! ethtool --version \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without ethtool tool\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+if ! ip link help 2\u003e\u00261 | grep gso_ipv4_max_size \u0026\u003e /dev/null; then\n+\techo \"SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link\"\n+\texit \"$ksft_skip\"\n+fi\n+\n+WORKDIR=$(mktemp -d)\n+trap cleanup EXIT\n+setup\n+for tunnel in vxlan geneve; do\n+\tfor tun_family in 4 6; do\n+\t\tfor traffic_family in 4 6; do\n+\t\t\tfor csum_offload in on off; do\n+\t\t\t\tsetup_tunnel \"$tunnel\" \"$tun_family\" \"$csum_offload\" || exit \"$?\"\n+\t\t\t\tdo_test \"$traffic_family\" \"$csum_offload\" || exit \"$?\"\n+\t\t\t\tcleanup_tunnel\n+\t\t\tdone\n+\t\tdone\n+\tdone\n+done\n"
}

2/1

2026/07/07 02:47

agent

patch-evaluator

29m

Model:

gemini-3.1-pro-preview

Args:

null

Results:

{
  "EnableConfigs": [
    "VXLAN",
    "GENEVE",
    "NET_FOU",
    "INET_ESP",
    "INET6_ESP",
    "L2TP",
    "IP_VS",
    "AMT",
    "WIREGUARD",
    "6LOWPAN_NHC_UDP",
    "NF_NAT_SNMP_BASIC",
    "NET_ACT_CSUM",
    "RDMA_RXE",
    "NETDEVSIM",
    "INET_PSP"
  ],
  "FocusSymbols": [
    "__udp_gso_segment",
    "udp_gro_complete",
    "udp4_gro_complete",
    "udp6_gro_complete",
    "udp_tunnel_xmit_skb",
    "udp_tunnel6_xmit_skb",
    "__skb_udp_tunnel_segment",
    "udp_gro_receive_segment",
    "fou_build_udp",
    "fou6_build_udp",
    "esp_output_udp_encap",
    "esp6_output_udp_encap",
    "l2tp_xmit_core",
    "ipvs_gue_encap",
    "tso_build_hdr",
    "skb_segment",
    "amt_send_discovery",
    "nsim_do_psp",
    "psp_write_headers",
    "nat_keepalive_send",
    "tcf_csum_ipv4_udp",
    "tcf_csum_ipv6_udp",
    "nf_nat_mangle_udp_packet",
    "udp_error",
    "snmp_translate",
    "udp_uncompress",
    "prepare_skb_header",
    "rdma_build_skb",
    "rxe_udp_encap_recv",
    "efx_gen_tun_header_udp",
    "i40e_tso",
    "iavf_tso",
    "ice_tso",
    "idpf_tso",
    "otx2_sqe_add_ext",
    "mlx5e_shampo_update_ipv4_udp_hdr",
    "mlx5e_shampo_update_ipv6_udp_hdr",
    "inet_rtm_getroute_build_skb",
    "fill_packet_ipv4",
    "fill_packet_ipv6"
  ],
  "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.",
  "WorthFuzzing": true
}

Instruction:

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Prompt:

For your convenience, here is the diff of the changes:
commit a82ad991569e9e2986e7c0d714f5587f5ee69273
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jul 7 02:47:49 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/infiniband/core/lag.c b/drivers/infiniband/core/lag.c
index 8fd80adfe833e7..00fe241737ffee 100644
--- a/drivers/infiniband/core/lag.c
+++ b/drivers/infiniband/core/lag.c
@@ -36,7 +36,7 @@ static struct sk_buff *rdma_build_skb(struct net_device *netdev,
 	uh->source =
 		htons(rdma_flow_label_to_udp_sport(ah_attr->grh.flow_label));
 	uh->dest = htons(ROCE_V2_UDP_DPORT);
-	uh->len = htons(sizeof(struct udphdr));
+	udp_set_len_short(uh, sizeof(struct udphdr));
 
 	if (is_ipv4) {
 		skb_push(skb, sizeof(struct iphdr));
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c b/drivers/infiniband/sw/rxe/rxe_net.c
index 3741b2c4b0bbfd..53daaf4c1eb2e0 100644
--- a/drivers/infiniband/sw/rxe/rxe_net.c
+++ b/drivers/infiniband/sw/rxe/rxe_net.c
@@ -242,7 +242,7 @@ static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
 	pkt->port_num = 1;
 	pkt->hdr = (u8 *)(udph + 1);
 	pkt->mask = RXE_GRH_MASK;
-	pkt->paylen = be16_to_cpu(udph->len) - sizeof(*udph);
+	pkt->paylen = udp_get_len_short(udph) - sizeof(*udph);
 
 	/* remove udp header */
 	skb_pull(skb, sizeof(struct udphdr));
@@ -305,7 +305,7 @@ static void prepare_udp_hdr(struct sk_buff *skb, __be16 src_port,
 
 	udph->dest = dst_port;
 	udph->source = src_port;
-	udph->len = htons(skb->len);
+	udp_set_len_short(udph, skb->len);
 	udph->check = 0;
 }
 
diff --git a/drivers/net/amt.c b/drivers/net/amt.c
index 5cf97c65576fc2..a44ffbb1816523 100644
--- a/drivers/net/amt.c
+++ b/drivers/net/amt.c
@@ -667,7 +667,7 @@ static void amt_send_discovery(struct amt_dev *amt)
 	udph		= udp_hdr(skb);
 	udph->source	= amt->gw_port;
 	udph->dest	= amt->relay_port;
-	udph->len	= htons(sizeof(*udph) + sizeof(*amtd));
+	udp_set_len_short(udph, sizeof(*udph) + sizeof(*amtd));
 	udph->check	= 0;
 	offset = skb_transport_offset(skb);
 	skb->csum = skb_checksum(skb, offset, skb->len - offset, 0);
@@ -760,7 +760,7 @@ static void amt_send_request(struct amt_dev *amt, bool v6)
 	udph		= udp_hdr(skb);
 	udph->source	= amt->gw_port;
 	udph->dest	= amt->relay_port;
-	udph->len	= htons(sizeof(*amtrh) + sizeof(*udph));
+	udp_set_len_short(udph, sizeof(*amtrh) + sizeof(*udph));
 	udph->check	= 0;
 	offset = skb_transport_offset(skb);
 	skb->csum = skb_checksum(skb, offset, skb->len - offset, 0);
@@ -2611,7 +2611,7 @@ static void amt_send_advertisement(struct amt_dev *amt, __be32 nonce,
 	udph		= udp_hdr(skb);
 	udph->source	= amt->relay_port;
 	udph->dest	= dport;
-	udph->len	= htons(sizeof(*amta) + sizeof(*udph));
+	udp_set_len_short(udph, sizeof(*amta) + sizeof(*udph));
 	udph->check	= 0;
 	offset = skb_transport_offset(skb);
 	skb->csum = skb_checksum(skb, offset, skb->len - offset, 0);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 894f2d06d39d07..ef5e657816f005 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -3129,7 +3129,7 @@ static int i40e_tso(struct i40e_tx_buffer *first, u8 *hdr_len,
 					 SKB_GSO_UDP_TUNNEL_CSUM)) {
 		if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) &&
 		    (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) {
-			l4.udp->len = 0;
+			udp_set_len_short(l4.udp, 0);
 
 			/* determine offset of outer transport header */
 			l4_offset = l4.hdr - skb->data;
diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
index 363c42bf3dcfee..c30abf17cf5d3c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
@@ -1774,7 +1774,7 @@ static int iavf_tso(struct iavf_tx_buffer *first, u8 *hdr_len,
 					 SKB_GSO_UDP_TUNNEL_CSUM)) {
 		if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) &&
 		    (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) {
-			l4.udp->len = 0;
+			udp_set_len_short(l4.udp, 0);
 
 			/* determine offset of outer transport header */
 			l4_offset = l4.hdr - skb->data;
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 4ca1a0602307d0..fdea2758adf155 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1893,7 +1893,7 @@ int ice_tso(struct ice_tx_buf *first, struct ice_tx_offload_params *off)
 					 SKB_GSO_UDP_TUNNEL_CSUM)) {
 		if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL) &&
 		    (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)) {
-			l4.udp->len = 0;
+			udp_set_len_short(l4.udp, 0);
 
 			/* determine offset of outer transport header */
 			l4_start = (u8)(l4.hdr - skb->data);
diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index 7f9056404f64fc..566b08ca3a6cb1 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -2871,7 +2871,7 @@ int idpf_tso(struct sk_buff *skb, struct idpf_tx_offload_params *off)
 				     (__force __wsum)htonl(paylen));
 		/* compute length of segmentation header */
 		off->tso_hdr_len = sizeof(struct udphdr) + l4_start;
-		l4.udp->len = htons(shinfo->gso_size + sizeof(struct udphdr));
+		udp_set_len_short(l4.udp, shinfo->gso_size + sizeof(struct udphdr));
 		break;
 	default:
 		return -EINVAL;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
index 625bb5a05344c0..8d2d607bc92f9c 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
@@ -750,7 +750,7 @@ static void otx2_sqe_add_ext(struct otx2_nic *pfvf, struct otx2_snd_queue *sq,
 				ext->lso_format = pfvf->hw.lso_udpv6_idx;
 			}
 
-			udph->len = htons(sizeof(struct udphdr));
+			udp_set_len_short(udph, sizeof(struct udphdr));
 		}
 	} else if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
 		ext->tstmp = 1;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 6fbc0441c4b845..04af54b704d823 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -1081,7 +1081,7 @@ static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq *rq, struct iphdr *
 	struct udphdr *uh;
 
 	uh = (struct udphdr *)(skb->data + udp_off);
-	uh->len = htons(skb->len - udp_off);
+	udp_set_len_short(uh, skb->len - udp_off);
 
 	if (uh->check)
 		uh->check = ~udp_v4_check(skb->len - udp_off, ipv4->saddr,
@@ -1100,7 +1100,7 @@ static void mlx5e_shampo_update_ipv6_udp_hdr(struct mlx5e_rq *rq, struct ipv6hdr
 	struct udphdr *uh;
 
 	uh = (struct udphdr *)(skb->data + udp_off);
-	uh->len = htons(skb->len - udp_off);
+	udp_set_len_short(uh, skb->len - udp_off);
 
 	if (uh->check)
 		uh->check = ~udp_v6_check(skb->len - udp_off, &ipv6->saddr,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
index accc26d1a872db..1dcdb86690bb74 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
@@ -113,7 +113,7 @@ static struct sk_buff *mlx5e_test_get_udp_skb(struct mlx5e_priv *priv)
 	/* Fill UDP header */
 	udph->source = htons(9);
 	udph->dest = htons(9); /* Discard Protocol */
-	udph->len = htons(sizeof(struct mlx5ehdr) + sizeof(struct udphdr));
+	udp_set_len_short(udph, sizeof(struct mlx5ehdr) + sizeof(struct udphdr));
 	udph->check = 0;
 
 	/* Fill IP header */
diff --git a/drivers/net/ethernet/sfc/falcon/selftest.c b/drivers/net/ethernet/sfc/falcon/selftest.c
index db4dd7fb77f5cb..4d29e0baf2ebe5 100644
--- a/drivers/net/ethernet/sfc/falcon/selftest.c
+++ b/drivers/net/ethernet/sfc/falcon/selftest.c
@@ -401,8 +401,8 @@ static void ef4_iterate_state(struct ef4_nic *efx)
 
 	/* Initialise udp header */
 	payload->udp.source = 0;
-	payload->udp.len = htons(sizeof(*payload) -
-				 offsetof(struct ef4_loopback_payload, udp));
+	udp_set_len_short(&payload->udp, sizeof(*payload) -
+			  offsetof(struct ef4_loopback_payload, udp));
 	payload->udp.check = 0;	/* checksum ignored */
 
 	/* Fill out payload */
diff --git a/drivers/net/ethernet/sfc/selftest.c b/drivers/net/ethernet/sfc/selftest.c
index 8ec76329237a49..dc716feb79cb5a 100644
--- a/drivers/net/ethernet/sfc/selftest.c
+++ b/drivers/net/ethernet/sfc/selftest.c
@@ -398,8 +398,8 @@ static void efx_iterate_state(struct efx_nic *efx)
 
 	/* Initialise udp header */
 	payload->udp.source = 0;
-	payload->udp.len = htons(sizeof(*payload) -
-				 offsetof(struct efx_loopback_payload, udp));
+	udp_set_len_short(&payload->udp, sizeof(*payload) -
+			  offsetof(struct efx_loopback_payload, udp));
 	payload->udp.check = 0;	/* checksum ignored */
 
 	/* Fill out payload */
diff --git a/drivers/net/ethernet/sfc/siena/selftest.c b/drivers/net/ethernet/sfc/siena/selftest.c
index 930643612df511..c74cf51313643d 100644
--- a/drivers/net/ethernet/sfc/siena/selftest.c
+++ b/drivers/net/ethernet/sfc/siena/selftest.c
@@ -399,8 +399,8 @@ static void efx_iterate_state(struct efx_nic *efx)
 
 	/* Initialise udp header */
 	payload->udp.source = 0;
-	payload->udp.len = htons(sizeof(*payload) -
-				 offsetof(struct efx_loopback_payload, udp));
+	udp_set_len_short(&payload->udp, sizeof(*payload) -
+			  offsetof(struct efx_loopback_payload, udp));
 	payload->udp.check = 0;	/* checksum ignored */
 
 	/* Fill out payload */
diff --git a/drivers/net/ethernet/sfc/tc_encap_actions.c b/drivers/net/ethernet/sfc/tc_encap_actions.c
index db222abef53b2a..c2ad3a358d2012 100644
--- a/drivers/net/ethernet/sfc/tc_encap_actions.c
+++ b/drivers/net/ethernet/sfc/tc_encap_actions.c
@@ -311,7 +311,7 @@ static void efx_gen_tun_header_udp(struct efx_tc_encap_action *encap, u8 len)
 	encap->encap_hdr_len += sizeof(*udp);
 
 	udp->dest = key->tp_dst;
-	udp->len = cpu_to_be16(sizeof(*udp) + len);
+	udp_set_len_short(udp, sizeof(*udp) + len);
 }
 
 static void efx_gen_tun_header_vxlan(struct efx_tc_encap_action *encap)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index a0c75886587c35..29e824bd90ca6b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -154,9 +154,9 @@ static struct sk_buff *stmmac_test_get_udp_skb(struct stmmac_priv *priv,
 	} else {
 		uhdr->source = htons(attr->sport);
 		uhdr->dest = htons(attr->dport);
-		uhdr->len = htons(sizeof(*shdr) + sizeof(*uhdr) + attr->size);
+		udp_set_len_short(uhdr, sizeof(*shdr) + sizeof(*uhdr) + attr->size);
 		if (attr->max_size)
-			uhdr->len = htons(attr->max_size -
+			udp_set_len_short(uhdr, attr->max_size -
 					  (sizeof(*ihdr) + sizeof(*ehdr)));
 		uhdr->check = 0;
 	}
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 396e1a113cd49e..a1639ad53077ec 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -631,7 +631,7 @@ static int geneve_post_decap_hint(const struct sock *sk, struct sk_buff *skb,
 
 	/* Adjust the nested UDP header len and checksum. */
 	uh = udp_hdr(skb);
-	uh->len = htons(skb->len - gro_hint->nested_tp_offset);
+	udp_set_len_short(uh, skb->len - gro_hint->nested_tp_offset);
 	if (uh->check) {
 		len = skb->len - gro_hint->nested_tp_offset;
 		skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL_CSUM;
@@ -1745,6 +1745,8 @@ static void geneve_setup(struct net_device *dev)
 	dev->max_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev->hard_header_len;
 
 	netif_keep_dst(dev);
+	netif_set_tso_max_size(dev, GSO_MAX_SIZE);
+
 	dev->priv_flags &= ~IFF_TX_SKB_SHARING;
 	dev->priv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_NO_QUEUE;
 	dev->lltx = true;
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index c1812a98365b78..a531548eb89138 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -1792,7 +1792,7 @@ static void push_udp(struct netpoll *np, struct sk_buff *skb, int len)
 	udph = udp_hdr(skb);
 	udph->source = htons(np->local_port);
 	udph->dest = htons(np->remote_port);
-	udph->len = htons(udp_len);
+	udp_set_len_short(udph, udp_len);
 
 	netpoll_udp_checksum(np, skb, len);
 }
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index aed9ad5f1b43af..f65b4cf4ea392b 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -845,7 +845,7 @@ static struct sk_buff *nsim_dev_trap_skb_build(void)
 	udph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);
 	get_random_bytes(&udph->source, sizeof(u16));
 	get_random_bytes(&udph->dest, sizeof(u16));
-	udph->len = htons(sizeof(struct udphdr) + data_len);
+	udp_set_len_short(udph, sizeof(struct udphdr) + data_len);
 
 	return skb;
 }
diff --git a/drivers/net/netdevsim/psample.c b/drivers/net/netdevsim/psample.c
index 717d157c3ae2b6..1e71c3da4def52 100644
--- a/drivers/net/netdevsim/psample.c
+++ b/drivers/net/netdevsim/psample.c
@@ -73,7 +73,7 @@ static struct sk_buff *nsim_dev_psample_skb_build(void)
 	udph = skb_put_zero(skb, sizeof(struct udphdr) + data_len);
 	get_random_bytes(&udph->source, sizeof(u16));
 	get_random_bytes(&udph->dest, sizeof(u16));
-	udph->len = htons(sizeof(struct udphdr) + data_len);
+	udp_set_len_short(udph, sizeof(struct udphdr) + data_len);
 
 	return skb;
 }
diff --git a/drivers/net/netdevsim/psp.c b/drivers/net/netdevsim/psp.c
index 59c990fdc79ecd..6b3532b5e360d5 100644
--- a/drivers/net/netdevsim/psp.c
+++ b/drivers/net/netdevsim/psp.c
@@ -84,6 +84,7 @@ nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,
 		struct iphdr *iph;
 		struct udphdr *uh;
 		__wsum csum;
+		int udplen;
 
 		/* Do not decapsulate. Receive the skb with the udp and psp
 		 * headers still there as if this is a normal udp packet.
@@ -91,19 +92,20 @@ nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,
 		 * provide a valid checksum here, so the skb isn't dropped.
 		 */
 		uh = udp_hdr(skb);
+		udplen = udp_get_len(skb, uh, skb_transport_offset(skb));
 		csum = skb_checksum(skb, skb_transport_offset(skb),
-				    ntohs(uh->len), 0);
+				    udplen, 0);
 
 		switch (skb->protocol) {
 		case htons(ETH_P_IP):
 			iph = ip_hdr(skb);
-			uh->check = udp_v4_check(ntohs(uh->len), iph->saddr,
+			uh->check = udp_v4_check(udplen, iph->saddr,
 						 iph->daddr, csum);
 			break;
 #if IS_ENABLED(CONFIG_IPV6)
 		case htons(ETH_P_IPV6):
 			ip6h = ipv6_hdr(skb);
-			uh->check = udp_v6_check(ntohs(uh->len), &ip6h->saddr,
+			uh->check = udp_v6_check(udplen, &ip6h->saddr,
 						 &ip6h->daddr, csum);
 			break;
 #endif
diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 67c367cc566233..3a32f067e701df 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -3370,6 +3370,8 @@ static void vxlan_setup(struct net_device *dev)
 	dev->mangleid_features = NETIF_F_GSO_PARTIAL;
 
 	netif_keep_dst(dev);
+	netif_set_tso_max_size(dev, GSO_MAX_SIZE);
+
 	dev->priv_flags |= IFF_NO_QUEUE;
 	dev->change_proto_down = true;
 	dev->lltx = true;
diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
index eb8851113654f5..824bbefce61c78 100644
--- a/drivers/net/wireguard/receive.c
+++ b/drivers/net/wireguard/receive.c
@@ -62,7 +62,7 @@ static int prepare_skb_header(struct sk_buff *skb, struct wg_device *wg)
 		 * to have UDP fields.
 		 */
 		return -EINVAL;
-	data_len = ntohs(udp->len);
+	data_len = udp_get_len_short(udp);
 	if (unlikely(data_len < sizeof(struct udphdr) ||
 		     data_len > skb->len - data_offset))
 		/* UDP packet is reporting too small of a size or lying about
diff --git a/include/linux/udp.h b/include/linux/udp.h
index ce56ebcee5cbcd..998906ec3b32ad 100644
--- a/include/linux/udp.h
+++ b/include/linux/udp.h
@@ -23,6 +23,33 @@ static inline struct udphdr *udp_hdr(const struct sk_buff *skb)
 	return (struct udphdr *)skb_transport_header(skb);
 }
 
+static inline unsigned int udp_get_len(const struct sk_buff *skb,
+				       const struct udphdr *uh,
+				       unsigned int dataoff)
+{
+	if (uh->len)
+		return ntohs(uh->len);
+	if (skb_is_gso(skb)) /* BIG TCP */
+		return skb->len - dataoff;
+	return 0;
+}
+
+static inline unsigned int udp_get_len_short(const struct udphdr *uh)
+{
+	return ntohs(uh->len);
+}
+
+static inline void udp_set_len(struct udphdr *uh, unsigned int len)
+{
+	uh->len = len < GRO_LEGACY_MAX_SIZE ? htons(len) : 0;
+}
+
+static inline void udp_set_len_short(struct udphdr *uh, unsigned int len)
+{
+	DEBUG_NET_WARN_ON_ONCE(len >= GRO_LEGACY_MAX_SIZE);
+	uh->len = htons(len);
+}
+
 #define UDP_HTABLE_SIZE_MIN_PERNET	128
 #define UDP_HTABLE_SIZE_MIN		(IS_ENABLED(CONFIG_BASE_SMALL) ? 128 : 256)
 #define UDP_HTABLE_SIZE_MAX		65536
diff --git a/include/trace/events/icmp.h b/include/trace/events/icmp.h
index 31559796949a78..09ae115099dfe2 100644
--- a/include/trace/events/icmp.h
+++ b/include/trace/events/icmp.h
@@ -44,7 +44,7 @@ TRACE_EVENT(icmp_send,
 			} else {
 				__entry->sport = ntohs(uh->source);
 				__entry->dport = ntohs(uh->dest);
-				__entry->ulen = ntohs(uh->len);
+				__entry->ulen = udp_get_len_short(uh);
 			}
 
 			p32 = (__be32 *) __entry->saddr;
diff --git a/lib/tests/blackhole_dev_kunit.c b/lib/tests/blackhole_dev_kunit.c
index 06834ab35f43c5..fa3e0533038d6f 100644
--- a/lib/tests/blackhole_dev_kunit.c
+++ b/lib/tests/blackhole_dev_kunit.c
@@ -46,7 +46,7 @@ static void test_blackholedev(struct kunit *test)
 	uh = (struct udphdr *)skb_push(skb, sizeof(struct udphdr));
 	skb_set_transport_header(skb, 0);
 	uh->source = uh->dest = htons(UDP_PORT);
-	uh->len = htons(data_len);
+	udp_set_len_short(uh, data_len);
 	uh->check = 0;
 	/* (Network) IPv6 */
 	ip6h = (struct ipv6hdr *)skb_push(skb, sizeof(struct ipv6hdr));
diff --git a/net/6lowpan/nhc_udp.c b/net/6lowpan/nhc_udp.c
index 0a506c77283dde..ed4227e6db7442 100644
--- a/net/6lowpan/nhc_udp.c
+++ b/net/6lowpan/nhc_udp.c
@@ -88,16 +88,16 @@ static int udp_uncompress(struct sk_buff *skb, size_t needed)
 	switch (lowpan_dev(skb->dev)->lltype) {
 	case LOWPAN_LLTYPE_IEEE802154:
 		if (lowpan_802154_cb(skb)->d_size)
-			uh.len = htons(lowpan_802154_cb(skb)->d_size -
-				       sizeof(struct ipv6hdr));
+			udp_set_len_short(&uh, lowpan_802154_cb(skb)->d_size -
+					  sizeof(struct ipv6hdr));
 		else
-			uh.len = htons(skb->len + sizeof(struct udphdr));
+			udp_set_len_short(&uh, skb->len + sizeof(struct udphdr));
 		break;
 	default:
-		uh.len = htons(skb->len + sizeof(struct udphdr));
+		udp_set_len_short(&uh, skb->len + sizeof(struct udphdr));
 		break;
 	}
-	pr_debug("uncompressed UDP length: src = %d", ntohs(uh.len));
+	pr_debug("uncompressed UDP length: src = %d", udp_get_len_short(&uh));
 
 	/* replace the compressed UDP head by the uncompressed UDP
 	 * header
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 8e185b31828853..5b4dd04d612476 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3005,7 +3005,7 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
 
 	udph->source = htons(pkt_dev->cur_udp_src);
 	udph->dest = htons(pkt_dev->cur_udp_dst);
-	udph->len = htons(datalen + 8);	/* DATA + udphdr */
+	udp_set_len_short(udph, datalen + 8);	/* DATA + udphdr */
 	udph->check = 0;
 
 	iph->ihl = 5;
@@ -3138,7 +3138,7 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
 	udplen = datalen + sizeof(struct udphdr);
 	udph->source = htons(pkt_dev->cur_udp_src);
 	udph->dest = htons(pkt_dev->cur_udp_dst);
-	udph->len = htons(udplen);
+	udp_set_len_short(udph, udplen);
 	udph->check = 0;
 
 	*(__be32 *) iph = htonl(0x60000000);	/* Version + flow */
diff --git a/net/core/selftests.c b/net/core/selftests.c
index 0a203d3fb9dcbe..36b949ae520b31 100644
--- a/net/core/selftests.c
+++ b/net/core/selftests.c
@@ -72,9 +72,9 @@ struct sk_buff *net_test_get_skb(struct net_device *ndev, u8 id,
 	} else {
 		uhdr->source = htons(attr->sport);
 		uhdr->dest = htons(attr->dport);
-		uhdr->len = htons(sizeof(*shdr) + sizeof(*uhdr) + attr->size);
+		udp_set_len_short(uhdr, sizeof(*shdr) + sizeof(*uhdr) + attr->size);
 		if (attr->max_size)
-			uhdr->len = htons(attr->max_size -
+			udp_set_len_short(uhdr, attr->max_size -
 					  (sizeof(*ihdr) + sizeof(*ehdr)));
 		uhdr->check = 0;
 	}
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 18dabb4e9cfa0e..6ae4c2b205f2ef 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4775,6 +4775,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 	struct sk_buff *tail = NULL;
 	struct sk_buff *list_skb = skb_shinfo(head_skb)->frag_list;
 	unsigned int mss = skb_shinfo(head_skb)->gso_size;
+	bool gso_by_frags = mss == GSO_BY_FRAGS;
 	unsigned int doffset = head_skb->data - skb_mac_header(head_skb);
 	unsigned int offset = doffset;
 	unsigned int tnl_hlen = skb_tnl_header_len(head_skb);
@@ -4790,7 +4791,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 	int nfrags, pos;
 
 	if ((skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY) &&
-	    mss != GSO_BY_FRAGS && mss != skb_headlen(head_skb)) {
+	    !gso_by_frags && mss != skb_headlen(head_skb)) {
 		struct sk_buff *check_skb;
 
 		for (check_skb = list_skb; check_skb; check_skb = check_skb->next) {
@@ -4818,7 +4819,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 	sg = !!(features & NETIF_F_SG);
 	csum = !!can_checksum_protocol(features, proto);
 
-	if (sg && csum && (mss != GSO_BY_FRAGS))  {
+	if (sg && csum && !gso_by_frags)  {
 		if (!(features & NETIF_F_GSO_PARTIAL)) {
 			struct sk_buff *iter;
 			unsigned int frag_len;
@@ -4852,9 +4853,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 		/* GSO partial only requires that we trim off any excess that
 		 * doesn't fit into an MSS sized block, so take care of that
 		 * now.
-		 * Cap len to not accidentally hit GSO_BY_FRAGS.
 		 */
-		partial_segs = min(len, GSO_BY_FRAGS - 1) / mss;
+		partial_segs = len / mss;
 		if (partial_segs > 1)
 			mss *= partial_segs;
 		else
@@ -4878,7 +4878,7 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 		int hsize;
 		int size;
 
-		if (unlikely(mss == GSO_BY_FRAGS)) {
+		if (unlikely(gso_by_frags)) {
 			len = list_skb->len;
 		} else {
 			len = head_skb->len - offset;
diff --git a/net/core/tso.c b/net/core/tso.c
index 347b3856ddb91f..d2934bcfa795f0 100644
--- a/net/core/tso.c
+++ b/net/core/tso.c
@@ -39,7 +39,8 @@ void tso_build_hdr(const struct sk_buff *skb, char *hdr, struct tso_t *tso,
 	} else {
 		struct udphdr *uh = (struct udphdr *)hdr;
 
-		uh->len = htons(sizeof(*uh) + size);
+		/* size is after segmentation. */
+		udp_set_len_short(uh, sizeof(*uh) + size);
 	}
 }
 EXPORT_SYMBOL(tso_build_hdr);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index dfc81ee969ae03..a6c18aea7498d8 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -323,7 +323,7 @@ static struct ip_esp_hdr *esp_output_udp_encap(struct sk_buff *skb,
 	uh = (struct udphdr *)esp->esph;
 	uh->source = sport;
 	uh->dest = dport;
-	uh->len = htons(len);
+	udp_set_len_short(uh, len);
 	uh->check = 0;
 
 	/* For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload
diff --git a/net/ipv4/fou_core.c b/net/ipv4/fou_core.c
index 865bd7205122d2..aef3ce1dec7aa2 100644
--- a/net/ipv4/fou_core.c
+++ b/net/ipv4/fou_core.c
@@ -1040,7 +1040,7 @@ static void fou_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,
 
 	uh->dest = e->dport;
 	uh->source = sport;
-	uh->len = htons(skb->len);
+	udp_set_len(uh, skb->len);
 	udp_set_csum(!(e->flags & TUNNEL_ENCAP_FLAG_CSUM), skb,
 		     fl4->saddr, fl4->daddr, skb->len);
 
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index a35ffedacc7c7f..155db067eaecbe 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -847,7 +847,7 @@ static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies_d
 	/* Construct UDP header */
 	b->udph.source = htons(68);
 	b->udph.dest = htons(67);
-	b->udph.len = htons(sizeof(struct bootp_pkt) - sizeof(struct iphdr));
+	udp_set_len_short(&b->udph, sizeof(struct bootp_pkt) - sizeof(struct iphdr));
 	/* UDP checksum not calculated -- explicitly allowed in BOOTP RFC */
 
 	/* Construct DHCP/BOOTP header */
@@ -1025,10 +1025,10 @@ static int __init ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, str
 	if (b->udph.source != htons(67) || b->udph.dest != htons(68))
 		goto drop;
 
-	if (ntohs(h->tot_len) < ntohs(b->udph.len) + sizeof(struct iphdr))
+	if (ntohs(h->tot_len) < udp_get_len_short(&b->udph) + sizeof(struct iphdr))
 		goto drop;
 
-	len = ntohs(b->udph.len) - sizeof(struct udphdr);
+	len = udp_get_len_short(&b->udph) - sizeof(struct udphdr);
 	ext_len = len - (sizeof(*b) -
 			 sizeof(struct iphdr) -
 			 sizeof(struct udphdr) -
diff --git a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c
index e540b86bd15b6b..4492bc548a66bf 100644
--- a/net/ipv4/netfilter/nf_nat_snmp_basic_main.c
+++ b/net/ipv4/netfilter/nf_nat_snmp_basic_main.c
@@ -127,7 +127,7 @@ static int snmp_translate(struct nf_conn *ct, int dir, struct sk_buff *skb)
 {
 	struct iphdr *iph = ip_hdr(skb);
 	struct udphdr *udph = (struct udphdr *)((__be32 *)iph + iph->ihl);
-	u16 datalen = ntohs(udph->len) - sizeof(struct udphdr);
+	u16 datalen = udp_get_len_short(udph) - sizeof(struct udphdr);
 	char *data = (unsigned char *)udph + sizeof(struct udphdr);
 	struct snmp_ctx ctx;
 	int ret;
@@ -181,7 +181,7 @@ static int help(struct sk_buff *skb, unsigned int protoff,
 	 * enough room for a UDP header.  Just verify the UDP length field so we
 	 * can mess around with the payload.
 	 */
-	if (ntohs(udph->len) != skb->len - (iph->ihl << 2)) {
+	if (udp_get_len_short(udph) != skb->len - (iph->ihl << 2)) {
 		nf_ct_helper_log(skb, ct, "dropping malformed packet\n");
 		return NF_DROP;
 	}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 3f3de5164d6e58..0825ed9837146c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -3187,7 +3187,7 @@ static struct sk_buff *inet_rtm_getroute_build_skb(__be32 src, __be32 dst,
 		udph = skb_put_zero(skb, sizeof(struct udphdr));
 		udph->source = sport;
 		udph->dest = dport;
-		udph->len = htons(sizeof(struct udphdr));
+		udp_set_len_short(udph, sizeof(struct udphdr));
 		udph->check = 0;
 		break;
 	}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 59248a59358ca5..2b9b55a147582b 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1108,7 +1108,8 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
 	uh = udp_hdr(skb);
 	uh->source = inet_sk(sk)->inet_sport;
 	uh->dest = fl4->fl4_dport;
-	uh->len = htons(len);
+	/* Datagram length checked in udp_sendmsg. */
+	udp_set_len_short(uh, len);
 	uh->check = 0;
 
 	if (cork->gso_size) {
@@ -2591,8 +2592,8 @@ int udp_rcv(struct sk_buff *skb)
 	struct rtable *rt = skb_rtable(skb);
 	struct net *net = dev_net(skb->dev);
 	struct sock *sk = NULL;
-	unsigned short ulen;
 	__be32 saddr, daddr;
+	unsigned int ulen;
 	struct udphdr *uh;
 	bool refcounted;
 	int drop_reason;
@@ -2606,7 +2607,7 @@ int udp_rcv(struct sk_buff *skb)
 		goto drop;		/* No space for header. */
 
 	uh   = udp_hdr(skb);
-	ulen = ntohs(uh->len);
+	ulen = udp_get_len(skb, uh, 0);
 	saddr = ip_hdr(skb)->saddr;
 	daddr = ip_hdr(skb)->daddr;
 
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 29651b1a0bc704..8f77c8788f6db0 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -279,11 +279,11 @@ static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,
 		 * segment instead of the entire frame.
 		 */
 		if (gso_partial && skb_is_gso(skb)) {
-			uh->len = htons(skb_shinfo(skb)->gso_size +
-					SKB_GSO_CB(skb)->data_offset +
-					skb->head - (unsigned char *)uh);
+			udp_set_len_short(uh, skb_shinfo(skb)->gso_size +
+					  SKB_GSO_CB(skb)->data_offset +
+					  skb->head - (unsigned char *)uh);
 		} else {
-			uh->len = htons(len);
+			udp_set_len_short(uh, len);
 		}
 
 		if (!need_csum)
@@ -468,7 +468,7 @@ static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
 	if (IS_ERR(skb))
 		return skb;
 
-	udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);
+	udp_set_len_short(udp_hdr(skb), sizeof(struct udphdr) + mss);
 
 	if (is_ipv6)
 		return __udpv6_gso_segment_list_csum(skb);
@@ -486,8 +486,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 	unsigned int mss;
 	bool copy_dtor;
 	__sum16 check;
-	__be16 newlen;
 	int ret = 0;
+	u16 newlen;
 
 	mss = skb_shinfo(gso_skb)->gso_size;
 	if (gso_skb->len <= sizeof(*uh) + mss)
@@ -564,8 +564,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 			(skb_shinfo(gso_skb)->tx_flags & SKBTX_ANY_TSTAMP);
 
 	/* compute checksum adjustment based on old length versus new */
-	newlen = htons(sizeof(*uh) + mss);
-	check = csum16_add(csum16_sub(uh->check, uh->len), newlen);
+	newlen = sizeof(*uh) + mss;
+	check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen));
 
 	for (;;) {
 		if (copy_dtor) {
@@ -577,7 +577,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 		if (!seg->next)
 			break;
 
-		uh->len = newlen;
+		udp_set_len_short(uh, newlen);
 		uh->check = check;
 
 		if (seg->ip_summed == CHECKSUM_PARTIAL)
@@ -594,11 +594,10 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
 	 * segment may not be full MSS, account for that in the checksum
 	 */
 	if (!skb_is_gso(seg))
-		newlen = htons(skb_tail_pointer(seg) -
-			       skb_transport_header(seg) + seg->data_len);
-	check = csum16_add(csum16_sub(uh->check, uh->len), newlen);
+		newlen = skb_tail_pointer(seg) - skb_transport_header(seg) + seg->data_len;
+	check = csum16_add(csum16_sub(uh->check, uh->len), htons(newlen));
 
-	uh->len = newlen;
+	udp_set_len_short(uh, newlen);
 	uh->check = check;
 
 	if (seg->ip_summed == CHECKSUM_PARTIAL)
@@ -708,12 +707,8 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
 		return NULL;
 	}
 
-	/* Do not deal with padded or malicious packets, sorry ! */
-	ulen = ntohs(uh->len);
-	if (ulen <= sizeof(*uh) || ulen != skb_gro_len(skb)) {
-		NAPI_GRO_CB(skb)->flush = 1;
-		return NULL;
-	}
+	ulen = udp_get_len_short(uh);
+
 	/* pull encapsulating udp header */
 	skb_gro_pull(skb, sizeof(struct udphdr));
 
@@ -742,7 +737,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
 		 * On len mismatch merge the first packet shorter than gso_size,
 		 * otherwise complete the GRO packet.
 		 */
-		if (ulen > ntohs(uh2->len) || flush) {
+		if (ulen > udp_get_len_short(uh2) || flush) {
 			pp = p;
 		} else {
 			if (NAPI_GRO_CB(skb)->is_flist) {
@@ -765,7 +760,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
 			}
 		}
 
-		if (ret || ulen != ntohs(uh2->len) ||
+		if (ret || ulen != udp_get_len_short(uh2) ||
 		    NAPI_GRO_CB(p)->count >= UDP_GRO_CNT_MAX)
 			pp = p;
 
@@ -783,8 +778,14 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
 	struct sk_buff *p;
 	struct udphdr *uh2;
 	unsigned int off = skb_gro_offset(skb);
+	unsigned int ulen;
 	int flush = 1;
 
+	/* Do not deal with padded or malicious packets, sorry! */
+	ulen = udp_get_len_short(uh);
+	if (ulen <= sizeof(*uh) || ulen != skb_gro_len(skb))
+		goto out;
+
 	/* We can do L4 aggregation only if the packet can't land in a tunnel
 	 * otherwise we could corrupt the inner stream. Detecting such packets
 	 * cannot be foolproof and the aggregation might still happen in some
@@ -915,12 +916,12 @@ static int udp_gro_complete_segment(struct sk_buff *skb)
 int udp_gro_complete(struct sk_buff *skb, int nhoff,
 		     udp_lookup_t lookup)
 {
-	__be16 newlen = htons(skb->len - nhoff);
 	struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
+	unsigned int newlen = skb->len - nhoff;
 	struct sock *sk;
 	int err;
 
-	uh->len = newlen;
+	udp_set_len(uh, newlen);
 
 	sk = INDIRECT_CALL_INET(lookup, udp6_lib_lookup_skb,
 				udp4_lib_lookup_skb, skb, uh->source, uh->dest);
@@ -957,7 +958,7 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
 
 	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
 	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
-		uh->len = htons(skb->len - nhoff);
+		udp_set_len(uh, skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
 		skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count;
diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
index 9ab3728f9630bf..a128fe85620d30 100644
--- a/net/ipv4/udp_tunnel_core.c
+++ b/net/ipv4/udp_tunnel_core.c
@@ -178,7 +178,7 @@ void udp_tunnel_xmit_skb(struct rtable *rt, struct sock *sk, struct sk_buff *skb
 
 	uh->dest = dst_port;
 	uh->source = src_port;
-	uh->len = htons(skb->len);
+	udp_set_len(uh, skb->len);
 
 	memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
 
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 296b57926abb98..72ec0d7d112090 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -230,7 +230,8 @@ static void esp_output_encap_csum(struct sk_buff *skb)
 	if (*skb_mac_header(skb) == IPPROTO_UDP) {
 		struct udphdr *uh = udp_hdr(skb);
 		struct ipv6hdr *ip6h = ipv6_hdr(skb);
-		int len = ntohs(uh->len);
+		/* esp6_output_udp_encap limits len to U16_MAX. */
+		int len = udp_get_len_short(uh);
 		unsigned int offset = skb_transport_offset(skb);
 		__wsum csum = skb_checksum(skb, offset, skb->len - offset, 0);
 
@@ -358,7 +359,7 @@ static struct ip_esp_hdr *esp6_output_udp_encap(struct sk_buff *skb,
 	uh = (struct udphdr *)esp->esph;
 	uh->source = sport;
 	uh->dest = dport;
-	uh->len = htons(len);
+	udp_set_len_short(uh, len);
 	uh->check = 0;
 
 	*skb_mac_header(skb) = IPPROTO_UDP;
diff --git a/net/ipv6/fou6.c b/net/ipv6/fou6.c
index 157765259e2f5f..4b659ca60ba9a8 100644
--- a/net/ipv6/fou6.c
+++ b/net/ipv6/fou6.c
@@ -30,7 +30,7 @@ static void fou6_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,
 
 	uh->dest = e->dport;
 	uh->source = sport;
-	uh->len = htons(skb->len);
+	udp_set_len(uh, skb->len);
 	udp6_set_csum(!(e->flags & TUNNEL_ENCAP_FLAG_CSUM6), skb,
 		      &fl6->saddr, &fl6->daddr, skb->len);
 
diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
index 9adb5775487fac..32525a051a6f08 100644
--- a/net/ipv6/ip6_udp_tunnel.c
+++ b/net/ipv6/ip6_udp_tunnel.c
@@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,
 	uh->dest = dst_port;
 	uh->source = src_port;
 
-	uh->len = htons(skb->len);
+	udp_set_len(uh, skb->len);
 
 	skb_dst_set(skb, dst);
 
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 392e18b9704544..02272466f4c298 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1081,12 +1081,12 @@ INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)
 	daddr = &ipv6_hdr(skb)->daddr;
 	uh = udp_hdr(skb);
 
-	ulen = ntohs(uh->len);
+	ulen = udp_get_len(skb, uh, 0);
 	if (ulen > skb->len)
 		goto short_packet;
 
 	/* Check for jumbo payload */
-	if (ulen == 0)
+	if (ulen == 0 && inet6_is_jumbogram(skb))
 		ulen = skb->len;
 
 	if (ulen < sizeof(*uh))
@@ -1369,7 +1369,8 @@ static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,
 	uh = udp_hdr(skb);
 	uh->source = fl6->fl6_sport;
 	uh->dest = fl6->fl6_dport;
-	uh->len = htons(len);
+	/* Datagram length checked in udpv6_sendmsg. */
+	udp_set_len_short(uh, len);
 	uh->check = 0;
 
 	if (cork->gso_size) {
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 778afc7453ce53..7370bcb80332ea 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -171,7 +171,7 @@ int udp6_gro_complete(struct sk_buff *skb, int nhoff)
 
 	/* do fraglist only if there is no outer UDP encap (or we already processed it) */
 	if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
-		uh->len = htons(skb->len - nhoff);
+		udp_set_len(uh, skb->len - nhoff);
 
 		skb_shinfo(skb)->gso_type |= (SKB_GSO_FRAGLIST|SKB_GSO_UDP_L4);
 		skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count;
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index f940914959b18e..4712cc41881a30 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1296,7 +1296,7 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, uns
 			ret = NET_XMIT_DROP;
 			goto out_unlock;
 		}
-		uh->len = htons(udp_len);
+		udp_set_len_short(uh, udp_len);
 
 		/* Calculate UDP checksum if configured to do so */
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index ce542ed4b013c8..c51ebd83a476fe 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -1100,7 +1100,7 @@ ipvs_gue_encap(struct net *net, struct sk_buff *skb,
 	dport = cp->dest->tun_port;
 	udph->dest = dport;
 	udph->source = sport;
-	udph->len = htons(skb->len);
+	udp_set_len(udph, skb->len);
 	udph->check = 0;
 
 	*next_protocol = IPPROTO_UDP;
diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
index cc9b7e5e19358d..a7edfefd6fd14b 100644
--- a/net/netfilter/nf_conntrack_proto_udp.c
+++ b/net/netfilter/nf_conntrack_proto_udp.c
@@ -41,11 +41,22 @@ static void udp_error_log(const struct sk_buff *skb,
 	nf_l4proto_log_invalid(skb, state, IPPROTO_UDP, "%s", msg);
 }
 
+static bool udp_validate_len(struct sk_buff *skb,
+			     const struct udphdr *hdr,
+			     unsigned int dataoff)
+{
+	unsigned int udplen = udp_get_len(skb, hdr, dataoff);
+	unsigned int skblen = skb->len - dataoff;
+
+	if (udplen > skblen || udplen < sizeof(*hdr))
+		return false;
+	return true;
+}
+
 static bool udp_error(struct sk_buff *skb,
 		      unsigned int dataoff,
 		      const struct nf_hook_state *state)
 {
-	unsigned int udplen = skb->len - dataoff;
 	const struct udphdr *hdr;
 	struct udphdr _hdr;
 
@@ -57,7 +68,7 @@ static bool udp_error(struct sk_buff *skb,
 	}
 
 	/* Truncated/malformed packets */
-	if (ntohs(hdr->len) > udplen || ntohs(hdr->len) < sizeof(*hdr)) {
+	if (!udp_validate_len(skb, hdr, dataoff)) {
 		udp_error_log(skb, state, "truncated/malformed packet");
 		return true;
 	}
diff --git a/net/netfilter/nf_log_syslog.c b/net/netfilter/nf_log_syslog.c
index e37b09b3203b75..71dff0eb672c43 100644
--- a/net/netfilter/nf_log_syslog.c
+++ b/net/netfilter/nf_log_syslog.c
@@ -301,7 +301,7 @@ nf_log_dump_udp_header(struct nf_log_buf *m,
 
 	/* Max length: 20 "SPT=65535 DPT=65535 " */
 	nf_log_buf_add(m, "SPT=%u DPT=%u LEN=%u ",
-		       ntohs(uh->source), ntohs(uh->dest), ntohs(uh->len));
+		       ntohs(uh->source), ntohs(uh->dest), udp_get_len_short(uh));
 
 out:
 	return 0;
diff --git a/net/netfilter/nf_nat_helper.c b/net/netfilter/nf_nat_helper.c
index bf591e6af0051a..3853f41db49953 100644
--- a/net/netfilter/nf_nat_helper.c
+++ b/net/netfilter/nf_nat_helper.c
@@ -161,7 +161,7 @@ nf_nat_mangle_udp_packet(struct sk_buff *skb,
 
 	/* update the length of the UDP packet */
 	datalen = skb->len - protoff;
-	udph->len = htons(datalen);
+	udp_set_len_short(udph, datalen);
 
 	/* fix udp checksum if udp checksum was previously calculated */
 	if (!udph->check && skb->ip_summed != CHECKSUM_PARTIAL)
diff --git a/net/psp/psp_main.c b/net/psp/psp_main.c
index 8b2f178e317cb8..c9c1a8826b7f92 100644
--- a/net/psp/psp_main.c
+++ b/net/psp/psp_main.c
@@ -231,7 +231,7 @@ static void psp_write_headers(struct net *net, struct sk_buff *skb, __be32 spi,
 		uh->source = udp_flow_src_port(net, skb, 0, 0, false);
 	}
 	uh->check = 0;
-	uh->len = htons(udp_len);
+	udp_set_len(uh, udp_len);
 
 	psph->nexthdr = IPPROTO_TCP;
 	psph->hdrlen = PSP_HDRLEN_NOOPT;
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 078d3a27130b8d..5fff52a8ca90dc 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -276,7 +276,7 @@ static int tcf_csum_ipv4_udp(struct sk_buff *skb, unsigned int ihl,
 		return 0;
 
 	iph = ip_hdr(skb);
-	ul = ntohs(udph->len);
+	ul = udp_get_len_short(udph);
 
 	if (udplite || udph->check) {
 
@@ -334,7 +334,7 @@ static int tcf_csum_ipv6_udp(struct sk_buff *skb, unsigned int ihl,
 		return 0;
 
 	ip6h = ipv6_hdr(skb);
-	ul = ntohs(udph->len);
+	ul = udp_get_len_short(udph);
 
 	udph->check = 0;
 
diff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c
index 458931062a04ef..906458f3d8c525 100644
--- a/net/xfrm/xfrm_nat_keepalive.c
+++ b/net/xfrm/xfrm_nat_keepalive.c
@@ -133,7 +133,7 @@ static void nat_keepalive_send(struct nat_keepalive *ka)
 	uh = skb_push(skb, sizeof(*uh));
 	uh->source = ka->encap_sport;
 	uh->dest = ka->encap_dport;
-	uh->len = htons(skb->len);
+	udp_set_len_short(uh, skb->len);
 	uh->check = 0;
 
 	skb->mark = ka->smark;
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 708d960ae07d5b..4cb0a0bc1eeace 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -13,6 +13,7 @@ TEST_PROGS := \
 	arp_ndisc_untracked_subnets.sh \
 	bareudp.sh \
 	big_tcp.sh \
+	big_tcp_tunnels.sh \
 	bind_bhash.sh \
 	bpf_offload.py \
 	bridge_stp_mode.sh \
diff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh
new file mode 100755
index 00000000000000..128a710e74ad5a
--- /dev/null
+++ b/tools/testing/selftests/net/big_tcp_tunnels.sh
@@ -0,0 +1,183 @@
+#!/usr/bin/env bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.
+
+SERVER_NS=$(mktemp -u server-XXXXXXXX)
+SERVER_IP4="192.168.1.1"
+SERVER_IP6="2001:db8::1:1"
+SERVER_IP4_TUN="192.168.2.1"
+SERVER_IP6_TUN="2001:db8::2:1"
+
+CLIENT_NS=$(mktemp -u client-XXXXXXXX)
+CLIENT_IP4="192.168.1.2"
+CLIENT_IP6="2001:db8::1:2"
+CLIENT_IP4_TUN="192.168.2.2"
+CLIENT_IP6_TUN="2001:db8::2:2"
+
+: "${PACKETS_THRESHOLD:=1000}"
+
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
+setup() {
+	ip netns add "$SERVER_NS"
+	ip netns add "$CLIENT_NS"
+	ip -netns "$SERVER_NS" link add link1 type veth peer name link0 netns "$CLIENT_NS"
+
+	ip -netns "$CLIENT_NS" link set link0 up
+	ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4/24" dev link0
+	ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6/112" dev link0 nodad
+	ip -netns "$CLIENT_NS" link set link0 \
+		gso_max_size 196608 gso_ipv4_max_size 196608 \
+		gro_max_size 196608 gro_ipv4_max_size 196608
+	ip -netns "$SERVER_NS" link set link1 up
+	ip -netns "$SERVER_NS" addr replace "$SERVER_IP4/24" dev link1
+	ip -netns "$SERVER_NS" addr replace "$SERVER_IP6/112" dev link1 nodad
+	ip -netns "$SERVER_NS" link set link1 \
+		gso_max_size 196608 gso_ipv4_max_size 196608 \
+		gro_max_size 196608 gro_ipv4_max_size 196608
+
+	ip netns exec "$SERVER_NS" netserver >/dev/null
+}
+
+setup_tunnel() {
+	if [ "$2" = 4 ]; then
+		SERVER_IP="$SERVER_IP4"
+		CLIENT_IP="$CLIENT_IP4"
+		echo "Setting up ${1^^} over IPv4, veth tx csum offload $3"
+	else
+		SERVER_IP="$SERVER_IP6"
+		CLIENT_IP="$CLIENT_IP6"
+		echo "Setting up ${1^^} over IPv6, veth tx csum offload $3"
+	fi
+
+	if [ "$1" = vxlan ]; then
+		ip -netns "$CLIENT_NS" link add tun0 type vxlan \
+			id 5001 remote "$SERVER_IP" local "$CLIENT_IP" dev link0 dstport 4789
+	else
+		ip -netns "$CLIENT_NS" link add tun0 type geneve \
+			id 5001 remote "$SERVER_IP"
+	fi
+	ip -netns "$CLIENT_NS" link set tun0 up
+	ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4_TUN/24" dev tun0
+	ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6_TUN/112" dev tun0 nodad
+	ip -netns "$CLIENT_NS" link set tun0 \
+		gso_max_size 196608 gso_ipv4_max_size 196608 \
+		gro_max_size 196608 gro_ipv4_max_size 196608
+	if [ "$1" = vxlan ]; then
+		ip -netns "$SERVER_NS" link add tun1 type vxlan \
+			id 5001 remote "$CLIENT_IP" local "$SERVER_IP" dev link1 dstport 4789
+	else
+		ip -netns "$SERVER_NS" link add tun1 type geneve \
+			id 5001 remote "$CLIENT_IP"
+	fi
+	ip -netns "$SERVER_NS" link set tun1 up
+	ip -netns "$SERVER_NS" addr replace "$SERVER_IP4_TUN/24" dev tun1
+	ip -netns "$SERVER_NS" addr replace "$SERVER_IP6_TUN/112" dev tun1 nodad
+	ip -netns "$SERVER_NS" link set tun1 \
+		gso_max_size 196608 gso_ipv4_max_size 196608 \
+		gro_max_size 196608 gro_ipv4_max_size 196608
+
+	ip netns exec "$CLIENT_NS" ethtool -K link0 tx-checksumming "$3" > /dev/null
+	ip netns exec "$SERVER_NS" ethtool -K link1 tx-checksumming "$3" > /dev/null
+}
+
+cleanup_tunnel() {
+	ip -netns "$CLIENT_NS" link del tun0
+	ip -netns "$SERVER_NS" link del tun1
+}
+
+cleanup() {
+	ip netns pids "$SERVER_NS" | xargs -r kill
+	ip netns pids "$CLIENT_NS" | xargs -r kill
+	ip netns del "$SERVER_NS"
+	ip netns del "$CLIENT_NS"
+	rm -rf "$WORKDIR"
+}
+
+do_test() {
+	# When tx csum offload is off, software GSO is performed before passing the
+	# packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify
+	# the software checksum path: if the checksum code is broken, these packets
+	# will be dropped.
+	if [ "$2" = on ]; then
+		CAPTURE_IFACE='link'
+	else
+		CAPTURE_IFACE='tun'
+	fi
+
+	ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}1" greater 65536 -w "$WORKDIR/server.pcap" 2> /dev/null &
+	TCPDUMP_SERVER_PID="$!"
+	ip netns exec "$CLIENT_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}0" greater 65536 -w "$WORKDIR/client.pcap" 2> /dev/null &
+	TCPDUMP_CLIENT_PID="$!"
+
+	# This filter doesn't capture all possible variants of SACK, but it's aimed
+	# at the typical one where SACK follows after [nop, nop, timestamp, nop,
+	# nop] (14 bytes after the 20-byte TCP header). IPv6 needs a separate match,
+	# because man tcpdump says:
+	# > Arithmetic expression against transport layer headers, like tcp[0], does
+	# > not work against IPv6 packets.  It only looks at IPv4 packets.
+	ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "tun1" '(tcp[tcpflags] & (tcp-syn|tcp-ack) = tcp-ack and tcp[34:2] & 0xffc3 = 0x0502) or (ip6[6] = 0x06 and ip6[53] & 0x12 = 0x10 and ip6[74:2] & 0xffc3 = 0x0502)' -w "$WORKDIR/sack.pcap" 2> /dev/null &
+	TCPDUMP_SACK_PID="$!"
+
+	if [ "$1" = 4 ]; then
+		SERVER_IP="$SERVER_IP4_TUN"
+		echo "Running IPv4 traffic in the tunnel"
+	else
+		SERVER_IP="$SERVER_IP6_TUN"
+		echo "Running IPv6 traffic in the tunnel"
+	fi
+
+	sleep 1 # Give tcpdump a second to spin up.
+	ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \
+		-m 80000 > /dev/null
+	sleep 1 # Give tcpdump a second to process buffered packets.
+	kill "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID"
+	wait "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID"
+	PACKETS_SERVER=$(tcpdump --count -r "$WORKDIR/server.pcap" 2> /dev/null | cut -d ' ' -f 1)
+	PACKETS_CLIENT=$(tcpdump --count -r "$WORKDIR/client.pcap" 2> /dev/null | cut -d ' ' -f 1)
+	PACKETS_SACK=$(tcpdump --count -r "$WORKDIR/sack.pcap" 2> /dev/null | cut -d ' ' -f 1)
+
+	echo "Captured BIG TCP RX packets: $PACKETS_SERVER"
+	echo "Captured BIG TCP TX packets: $PACKETS_CLIENT"
+	echo "Captured TCP SACK packets: $PACKETS_SACK"
+	[ "$PACKETS_SERVER" -gt "$PACKETS_THRESHOLD" ] || return 1
+	[ "$PACKETS_CLIENT" -gt "$PACKETS_THRESHOLD" ] || return 1
+	[ "$PACKETS_SACK" -lt "$(( PACKETS_CLIENT / 2 ))" ] || return 1
+}
+
+if ! netperf -V &> /dev/null; then
+	echo "SKIP: Could not run test without netperf tool"
+	exit "$ksft_skip"
+fi
+
+if ! tcpdump --version &> /dev/null; then
+	echo "SKIP: Could not run test without tcpdump tool"
+	exit "$ksft_skip"
+fi
+
+if ! ethtool --version &> /dev/null; then
+	echo "SKIP: Could not run test without ethtool tool"
+	exit "$ksft_skip"
+fi
+
+if ! ip link help 2>&1 | grep gso_ipv4_max_size &> /dev/null; then
+	echo "SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link"
+	exit "$ksft_skip"
+fi
+
+WORKDIR=$(mktemp -d)
+trap cleanup EXIT
+setup
+for tunnel in vxlan geneve; do
+	for tun_family in 4 6; do
+		for traffic_family in 4 6; do
+			for csum_offload in on off; do
+				setup_tunnel "$tunnel" "$tun_family" "$csum_offload" || exit "$?"
+				do_test "$traffic_family" "$csum_offload" || exit "$?"
+				cleanup_tunnel
+			done
+		done
+	done
+done

3/2

2026/07/07 02:47

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 23760
							output: 23
							thoughts: 854

Thoughts:

**Fuzzing Strategy for UDP Length Handling with BIG TCP Support**

Okay, so I'm looking at this patch and it seems like a pretty significant overhaul of UDP length handling, specifically related to supporting BIG TCP, likely for tunneling scenarios like VXLAN and GENEVE. They're introducing `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` in `include/linux/udp.h`, and applying these across a *lot* of core networking code: Infiniband drivers, Intel Ethernet, Geneve, VXLAN, and core UDP (IPv4 and IPv6) plus offload paths. Essentially, they're replacing direct manipulations of the UDP header length with these new functions.

The key thing here is the shift to `udp_set_len_short` and `udp_get_len_short`, or their larger counterparts. This signals a fundamental change – the explicit handling of larger GSO (Generic Segmentation Offload) sizes, likely needed for the aforementioned tunnels to support oversized UDP packets, now becoming possible.

Given this, I have a few specific thoughts. First, this is absolutely worth fuzzing. It touches core UDP infrastructure, GRO (Generic Receive Offload), GSO, TSO (Transmit Segment Offload), IPv4, IPv6, and tunnel implementations. The risk of introducing subtle bugs here is substantial, and the impact of those bugs could be significant.

Now, let's nail down where to focus my fuzzing efforts. After reviewing the changes, several functions jump out as high-value targets. I need to balance impact with practical considerations. I'd like to avoid the super-hot paths like `udp_rcv` and `udpv6_rcv`. Although they are important, they are less likely to produce unique results and more likely to result in crashes due to complex state and dependencies. However, I should fuzz the following:

* `udp_gro_receive` and `udp_gro_complete` (and `udp4_gro_complete` and `udp6_gro_complete`). They're crucial for GRO, where large packets are assembled, so any issues with the new length handling there could cause data corruption or crashes.
* `__udp_gso_segment` and `udp_gro_receive_segment`: These are directly involved in segmenting packets for GSO which is the focus of this patch.
* `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb`: these are important to test since these directly handle the tunneling logic.
* `skb_segment`: A more general function modified by this patch, handling the segmentation logic.

I should also check the configuration dependencies. Based on the patch, it seems likely that `CONFIG_NET`, `CONFIG_INET`, `CONFIG_IPV6`, `CONFIG_VXLAN`, `CONFIG_GENEVE`, and `CONFIG_NET_UDP_TUNNEL` will be required. I should ensure that all of these are enabled in my fuzzing environment. The VXLAN and GENEVE drivers are also directly modified, indicating their importance. I might also want to look at `geneve_setup` and `vxlan_setup` since they're setting the `netif_set_tso_max_size(dev, GSO_MAX_SIZE)`.

In summary, this requires a targeted fuzzing campaign, focused on a few carefully selected, but high impact functions, and requiring a configuration that supports the relevant protocols and tunneling technologies.

4/2

2026/07/07 02:48

tool

grepper

Args:

{
  "Expression": "config VXLAN",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=216=config IPVTAP\n--\ndrivers/net/Kconfig-229-\ndrivers/net/Kconfig:230:config VXLAN\ndrivers/net/Kconfig-231-\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\n"
}

5/2

2026/07/07 02:48

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 25476
							output: 24
							thoughts: 9

Thoughts:

Okay, here's my summarized thought process, presented as if it were my own:

**Network Virtualization Protocols: A Quick Assessment**

Alright, let's see... VXLAN and GENEVE. Hmm, both are solid choices in the realm of network virtualization. They each offer the encapsulation capabilities we need for that overlay networking magic, allowing us to build flexible and scalable virtual networks on top of existing physical infrastructure. They're well-established, and have matured to a level where there's good support and interoperability to consider. No major red flags leap to mind. In the grand scheme of things, they offer the key function we need.

6/2

2026/07/07 02:48

tool

grepper

Args:

{
  "Expression": "config GENEVE",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=230=config VXLAN\n--\ndrivers/net/Kconfig-244-\ndrivers/net/Kconfig:245:config GENEVE\ndrivers/net/Kconfig-246-\ttristate \"Generic Network Virtualization Encapsulation\"\n"
}

7/2

2026/07/07 02:48

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 25727
							output: 25
							thoughts: 53

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**IPv6 Configuration Concerns**

Hmm, this situation has me thinking... *`CONFIG_IPV6`*. That seems like a given, a foundational setting. It's practically standard, isn't it? I'd be surprised if it *wasn't* already enabled.

But then, *`CONFIG_NET_FOU`* catches my eye. That's immediately relevant. The fact that the code touches *`net/ipv4/fou_core.c`* and *`net/ipv6/fou6.c`* is a pretty strong indicator. This implies that the change has implications for both IPv4 and IPv6 traffic encapsulation, which is something I need to carefully consider given its potential impact. It’s got my attention now.

8/2

2026/07/07 02:49

tool

grepper

Args:

{
  "Expression": "config NET_FOU",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/Kconfig=316=config NET_UDP_TUNNEL\n--\nnet/ipv4/Kconfig-320-\nnet/ipv4/Kconfig:321:config NET_FOU\nnet/ipv4/Kconfig-322-\ttristate \"IP: Foo (IP protocols) over UDP\"\n--\nnet/ipv4/Kconfig-329-\nnet/ipv4/Kconfig:330:config NET_FOU_IP_TUNNELS\nnet/ipv4/Kconfig-331-\tbool \"IP: FOU encapsulation of IP tunnels\"\n"
}

9/2

2026/07/07 02:49

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 26146
							output: 25
							thoughts: 47

Thoughts:

Okay, let's dive into this code.

**Investigating Potential ESP Security Implications**

My immediate focus, given modifications to both `net/ipv4/esp4.c` and `net/ipv6/esp6.c`, is the ESP protocol implementation. It's time to check the configuration options, specifically `CONFIG_INET_ESP` and `CONFIG_INET6_ESP`. Any changes to the core ESP implementation, especially in IPv4 and IPv6, warrant a close look at the build configuration to understand which systems this potentially impacts. I need to understand whether these modifications trigger any security considerations for ESP traffic across either protocol, or if the modifications relate to a feature that is not enabled.

10/2

2026/07/07 02:49

tool

grepper

Args:

{
  "Expression": "config INET_ESP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/Kconfig=339=config INET_AH\n--\nnet/ipv4/Kconfig-353-\nnet/ipv4/Kconfig:354:config INET_ESP\nnet/ipv4/Kconfig-355-\ttristate \"IP: ESP transformation\"\n--\nnet/ipv4/Kconfig-368-\nnet/ipv4/Kconfig:369:config INET_ESP_OFFLOAD\nnet/ipv4/Kconfig-370-\ttristate \"IP: ESP transformation offload\"\n--\nnet/ipv4/Kconfig-381-\nnet/ipv4/Kconfig:382:config INET_ESPINTCP\nnet/ipv4/Kconfig-383-\tbool \"IP: ESP in TCP encapsulation (RFC 8229)\"\n"
}

11/2

2026/07/07 02:49

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 26578
							output: 26
							thoughts: 12

Thoughts:

Here's a summary of my thought process:

**Verifying IPv6 ESP Configuration**

Okay, let's just make sure we haven't missed anything obvious. First, I need to check the `CONFIG_INET6_ESP` configuration option. It's fundamental to IPv6 Encapsulating Security Payload (ESP) operation, so this has to be the first step in ensuring a correct and functional IPv6 security implementation. I need to confirm whether this is enabled. Without it, the whole thing falls apart. No ESP, no protected traffic. Let's make sure it's set correctly.

12/2

2026/07/07 02:49

tool

grepper

Args:

{
  "Expression": "config INET6_ESP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv6/Kconfig=47=config INET6_AH\n--\nnet/ipv6/Kconfig-61-\nnet/ipv6/Kconfig:62:config INET6_ESP\nnet/ipv6/Kconfig-63-\ttristate \"IPv6: ESP transformation\"\n--\nnet/ipv6/Kconfig-76-\nnet/ipv6/Kconfig:77:config INET6_ESP_OFFLOAD\nnet/ipv6/Kconfig-78-\ttristate \"IPv6: ESP transformation offload\"\n--\nnet/ipv6/Kconfig-89-\nnet/ipv6/Kconfig:90:config INET6_ESPINTCP\nnet/ipv6/Kconfig-91-\tbool \"IPv6: ESP in TCP encapsulation (RFC 8229)\"\n"
}

13/2

2026/07/07 02:49

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 26952
							output: 24
							thoughts: 11

Thoughts:

Here's my thought process, as it is:

**Checking `CONFIG_L2TP`**

Okay, first things first, let's zero in on `CONFIG_L2TP`. As an expert, I know exactly what this represents. Time to verify its status. Is it enabled? Disabled? Maybe modular? Understanding the current state of this configuration option is the foundation. I need to understand what its impact will be.

I'm thinking, "what is the current state? Does this meet the needs?"

14/2

2026/07/07 02:51

tool

grepper

Args:

{
  "Expression": "config L2TP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/l2tp/Kconfig-5-\nnet/l2tp/Kconfig:6:menuconfig L2TP\nnet/l2tp/Kconfig-7-\ttristate \"Layer Two Tunneling Protocol (L2TP)\"\n--\nnet/l2tp/Kconfig-35-\nnet/l2tp/Kconfig:36:config L2TP_DEBUGFS\nnet/l2tp/Kconfig-37-\ttristate \"L2TP debugfs support\"\n--\nnet/l2tp/Kconfig-48-\nnet/l2tp/Kconfig:49:config L2TP_V3\nnet/l2tp/Kconfig-50-\tbool \"L2TPv3 support\"\n--\nnet/l2tp/Kconfig-69-\nnet/l2tp/Kconfig:70:config L2TP_IP\nnet/l2tp/Kconfig-71-\ttristate \"L2TP IP encapsulation for L2TPv3\"\n--\nnet/l2tp/Kconfig-86-\nnet/l2tp/Kconfig:87:config L2TP_ETH\nnet/l2tp/Kconfig-88-\ttristate \"L2TP ethernet pseudowire support for L2TPv3\"\n"
}

15/2

2026/07/07 02:51

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 27413
							output: 24
							thoughts: 11

Thoughts:

Here's my take:

**Investigating the Configuration**

Alright, let's dive in. The task before me is clear: I need to ascertain the status of `CONFIG_IP_VS`. Time to check. This is standard operating procedure, really; always start with the base configuration. Knowing the state of this parameter is fundamental to understanding the overall picture and how everything else interacts. This will set the stage for further analysis and decisions. It is the groundwork that must be laid before I can proceed any further.

16/2

2026/07/07 02:51

tool

grepper

Args:

{
  "Expression": "config IP_VS",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/netfilter/ipvs/Kconfig-4-#\nnet/netfilter/ipvs/Kconfig:5:menuconfig IP_VS\nnet/netfilter/ipvs/Kconfig-6-\ttristate \"IP virtual server support\"\n--\nnet/netfilter/ipvs/Kconfig=286=comment 'IPVS SH scheduler'\nnet/netfilter/ipvs/Kconfig-287-\nnet/netfilter/ipvs/Kconfig:288:config IP_VS_SH_TAB_BITS\nnet/netfilter/ipvs/Kconfig-289-\tint \"IPVS source hashing table size (the Nth power of 2)\"\n--\nnet/netfilter/ipvs/Kconfig=301=comment 'IPVS MH scheduler'\nnet/netfilter/ipvs/Kconfig-302-\nnet/netfilter/ipvs/Kconfig:303:config IP_VS_MH_TAB_INDEX\nnet/netfilter/ipvs/Kconfig-304-\tint \"IPVS maglev hashing table index of size (the prime numbers)\"\n"
}

17/2

2026/07/07 02:51

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 27826
							output: 22
							thoughts: 432

Thoughts:

**Analyzing the BIG TCP over UDP Tunnel Patch**

Okay, so this patch is all about enabling BIG TCP over UDP tunnels. Right, let's break down the core of this. The key functions that are being touched are `udp_gro_receive`, `udp_gro_complete`, and its IPv4/IPv6 counterparts (`udp4_gro_complete`, `udp6_gro_complete`), along with the segmentation functions `__udp_gso_segment` and `skb_segment`, and the tunnel transmission functions `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb`.

First, I need to understand the impact on performance. I'm thinking, is `udp_gro_receive` a potential hot path? Yup, it's called for every single UDP packet when GRO is involved. On the other hand, `__udp_gso_segment` seems important for UDP GSO packets, while `udp_gro_complete` is crucial for finishing off a UDP GRO packet. And, obviously, `udp_tunnel_xmit_skb` handles the transmission through the UDP tunnel.

To keep track, I'll select `__udp_gso_segment`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, and `skb_segment` as my FocusSymbols for closer inspection. I'll also check out `geneve_setup` and `vxlan_setup`, because even though they are just setting the `netif_set_tso_max_size(dev, GSO_MAX_SIZE)` for the interface, it's important to understand the overall context.

Now, let's talk about the required configurations. I see that this will rely on `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, and `IP_VS`. I need to ensure all these are enabled.

Specifically, I need to verify that `CONFIG_NET_FOU` is sufficient or if `CONFIG_NET_FOU_IP_TUNNELS` is also needed. Looking at the code, it looks like `NET_FOU` is indeed enough for `net/ipv4/fou_core.c` and `net/ipv6/fou6.c`.

Finally, since I'm reviewing everything, I'll check `drivers/net/amt.c` to see if `CONFIG_AMT` is relevant here as well.

18/2

2026/07/07 02:51

tool

grepper

Args:

{
  "Expression": "config AMT",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=289=config PFCP\n--\ndrivers/net/Kconfig-301-\ndrivers/net/Kconfig:302:config AMT\ndrivers/net/Kconfig-303-\ttristate \"Automatic Multicast Tunneling (AMT)\"\n"
}

19/2

2026/07/07 02:52

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 28928
							output: 23
							thoughts: 21

Thoughts:

Here's my take on the thought process, considering I'm an expert:

**Diving into the Kernel Network Console**

Alright, let's get down to brass tacks. The objective is clear: dissect the network console functionality within the kernel. My first instinct, as always when I’m getting my bearings, is to zero in on the core implementation. So, my initial thought is to navigate directly to `drivers/net/netconsole.c`. That file is the most likely location for the meat of the network console driver. And, crucially, I need to confirm the configuration option that activates it. So I'm thinking, "Is `CONFIG_NETCONSOLE` defined?" That's my starting point. That macro will quickly tell me if this particular driver is even compiled into the kernel being analyzed. I want to check all of my dependencies, and then move on to checking the functions and variables associated with those dependencies. After that I can determine how this all works.

20/2

2026/07/07 02:52

tool

grepper

Args:

{
  "Expression": "config NETCONSOLE",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=318=config MACSEC\n--\ndrivers/net/Kconfig-326-\ndrivers/net/Kconfig:327:config NETCONSOLE\ndrivers/net/Kconfig-328-\ttristate \"Network console logging support\"\n--\ndrivers/net/Kconfig-333-\ndrivers/net/Kconfig:334:config NETCONSOLE_DYNAMIC\ndrivers/net/Kconfig-335-\tbool \"Dynamic reconfiguration of logging targets\"\n--\ndrivers/net/Kconfig-344-\ndrivers/net/Kconfig:345:config NETCONSOLE_EXTENDED_LOG\ndrivers/net/Kconfig-346-\tbool \"Set kernel extended message by default\"\n--\ndrivers/net/Kconfig-354-\ndrivers/net/Kconfig:355:config NETCONSOLE_PREPEND_RELEASE\ndrivers/net/Kconfig-356-\tbool \"Prepend kernel release version in the message by default\"\n"
}

21/2

2026/07/07 02:52

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 29423
							output: 25
							thoughts: 25

Thoughts:

Here's my take on the thought process, as if I were the one thinking it:

**Diving into WireGuard Receive Path**

Alright, time to dig into the WireGuard receive path. I need to understand how the data's flowing. My first stop, as always, will be the source code. Let's see... I'm focusing on the receive side, so `drivers/net/wireguard/receive.c` seems like the logical place to start. And, of course, I should make absolutely certain that `CONFIG_WIREGUARD` is enabled, because if that isn't true, I'm wasting my time looking into code that won't even be compiled. Let's just double-check that. That's always my first step to be sure I am looking at the code that is actually run.

22/2

2026/07/07 02:52

tool

grepper

Args:

{
  "Expression": "config WIREGUARD",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=59=config DUMMY\n--\ndrivers/net/Kconfig-73-\ndrivers/net/Kconfig:74:config WIREGUARD\ndrivers/net/Kconfig-75-\ttristate \"WireGuard secure network tunnel\"\n--\ndrivers/net/Kconfig-91-\ndrivers/net/Kconfig:92:config WIREGUARD_DEBUG\ndrivers/net/Kconfig-93-\tbool \"Debugging checks and verbose messages\"\n"
}

23/2

2026/07/07 02:53

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 29781
							output: 30
							thoughts: 31

Thoughts:

Here's my take on the thought process, as if it were my own:

**Investigating the UDP Neighbor Header Compression Implementation**

Okay, time to dive into the UDP Neighbor Header Compression code. First things first: let's zero in on `net/6lowpan/nhc_udp.c`. That's where I expect to find the meat of this implementation. And I need to be absolutely sure that the configuration is enabled, so I'll double-check that `CONFIG_6LOWPAN_NHC_UDP` is set. Gotta make sure it's compiled in before I waste time looking at something that isn't even part of the current build. This is standard procedure; always start by verifying the prerequisites before you start analyzing the core functionality.

24/2

2026/07/07 02:53

tool

grepper

Args:

{
  "Expression": "config 6LOWPAN_NHC_UDP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/6lowpan/Kconfig=59=config 6LOWPAN_NHC_ROUTING\n--\nnet/6lowpan/Kconfig-64-\nnet/6lowpan/Kconfig:65:config 6LOWPAN_NHC_UDP\nnet/6lowpan/Kconfig-66-\ttristate \"UDP Header Support\"\n"
}

25/2

2026/07/07 02:53

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 30101
							output: 29
							thoughts: 39

Thoughts:

Here's a summary of my thought process, as requested:

**Diving into the SNMP NAT Implementation**

Okay, so I need to understand how SNMP traffic is being handled in this NAT setup. My first port of call is going to be the code related to the `nf_nat_snmp_basic` module, specifically `net/ipv4/netfilter/nf_nat_snmp_basic_main.c`. The fact that it's in the `netfilter` directory tells me it's operating at the kernel's network level, which is what I'd expect. Now, I need to make sure the relevant functionality is even *enabled* in this build, so I need to verify that `CONFIG_NF_NAT_SNMP_BASIC` is defined. This will be the starting point to understand the specifics of this NAT implementation.

26/2

2026/07/07 02:53

tool

grepper

Args:

{
  "Expression": "config NF_NAT_SNMP_BASIC",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/netfilter/Kconfig=99=if NF_NAT\nnet/ipv4/netfilter/Kconfig:100:config NF_NAT_SNMP_BASIC\nnet/ipv4/netfilter/Kconfig-101-\ttristate \"Basic SNMP-ALG support\"\n"
}

27/2

2026/07/07 02:54

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 30434
							output: 24
							thoughts: 85

Thoughts:

Here's my thought process, as it stands:

**Navigating Kernel Configuration Options**

Okay, so I'm thinking about something related to network traffic and need to figure out which kernel configuration options are relevant. My first instinct is to check out the conntrack side of things, specifically the UDP protocol handler. I should probably start by examining `net/netfilter/nf_conntrack_proto_udp.c` to see if `CONFIG_NF_CT_PROTO_UDP` is enabled. Though, honestly, often the dependency is just the broader `CONFIG_NF_CONNTRACK` option.

Then, since I'm already in this investigative mood, I'll move over to the XFRM subsystem. Given the context, the NAT keepalive functionality is likely to be relevant. Let's see if the configuration option `CONFIG_XFRM_NAT_KEEPALIVE` is enabled in `net/xfrm/xfrm_nat_keepalive.c`. That should give me some direction.

28/2

2026/07/07 02:54

tool

grepper

Args:

{
  "Expression": "config XFRM",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/xfrm/Kconfig-4-#\nnet/xfrm/Kconfig:5:config XFRM\nnet/xfrm/Kconfig-6-\tbool\n--\nnet/xfrm/Kconfig-10-\nnet/xfrm/Kconfig:11:config XFRM_OFFLOAD\nnet/xfrm/Kconfig-12-\tbool\nnet/xfrm/Kconfig-13-\nnet/xfrm/Kconfig:14:config XFRM_ALGO\nnet/xfrm/Kconfig-15-\ttristate\n--\nnet/xfrm/Kconfig=22=if INET\nnet/xfrm/Kconfig:23:config XFRM_USER\nnet/xfrm/Kconfig-24-\ttristate \"Transformation user configuration interface\"\n--\nnet/xfrm/Kconfig-31-\nnet/xfrm/Kconfig:32:config XFRM_USER_COMPAT\nnet/xfrm/Kconfig-33-\ttristate \"Compatible ABI support\"\n--\nnet/xfrm/Kconfig-42-\nnet/xfrm/Kconfig:43:config XFRM_INTERFACE\nnet/xfrm/Kconfig-44-\ttristate \"Transformation virtual interface\"\n--\nnet/xfrm/Kconfig-50-\nnet/xfrm/Kconfig:51:config XFRM_SUB_POLICY\nnet/xfrm/Kconfig-52-\tbool \"Transformation sub policy support\"\n--\nnet/xfrm/Kconfig-60-\nnet/xfrm/Kconfig:61:config XFRM_MIGRATE\nnet/xfrm/Kconfig-62-\tbool \"Transformation migrate database\"\n--\nnet/xfrm/Kconfig-71-\nnet/xfrm/Kconfig:72:config XFRM_STATISTICS\nnet/xfrm/Kconfig-73-\tbool \"Transformation statistics\"\n--\nnet/xfrm/Kconfig-83-# RFC 8221 lists as MUST be implemented.\nnet/xfrm/Kconfig:84:config XFRM_AH\nnet/xfrm/Kconfig-85-\ttristate\n--\nnet/xfrm/Kconfig-92-# algorithms that RFC 8221 lists as MUST be implemented.\nnet/xfrm/Kconfig:93:config XFRM_ESP\nnet/xfrm/Kconfig-94-\ttristate\n--\nnet/xfrm/Kconfig-105-\nnet/xfrm/Kconfig:106:config XFRM_IPCOMP\nnet/xfrm/Kconfig-107-\ttristate\n--\nnet/xfrm/Kconfig=125=config NET_KEY_MIGRATE\n--\nnet/xfrm/Kconfig-140-\nnet/xfrm/Kconfig:141:config XFRM_IPTFS\nnet/xfrm/Kconfig-142-\ttristate \"IPsec IP-TFS/AGGFRAG (RFC 9347) encapsulation support\"\n--\nnet/xfrm/Kconfig-156-\nnet/xfrm/Kconfig:157:config XFRM_ESPINTCP\nnet/xfrm/Kconfig-158-\tbool\n"
}

29/2

2026/07/07 02:54

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 31551
							output: 27
							thoughts: 43

Thoughts:

Here's my take on those thoughts:

**XFRM & the IPsec Connection**

Okay, so XFRM is basically baked in if IPsec is enabled. That makes sense, right? They're tightly coupled. Now, I want to drill down a bit further. Let's see how the checksum offload is being handled, so I'm going to take a look at `net/sched/act_csum.c` and specifically, I'm going to double-check the `CONFIG_NET_ACT_CSUM` config option. I need to understand if the checksum calculations are being offloaded, or if other considerations are at play here.

30/2

2026/07/07 02:54

tool

grepper

Args:

{
  "Expression": "config NET_ACT_CSUM",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/sched/Kconfig=797=config NET_ACT_SKBEDIT\n--\nnet/sched/Kconfig-807-\nnet/sched/Kconfig:808:config NET_ACT_CSUM\nnet/sched/Kconfig-809-\ttristate \"Checksum Updating\"\n"
}

31/2

2026/07/07 02:54

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 31849
							output: 26
							thoughts: 34

Thoughts:

Here's my analysis of the provided thought process, tailored for an expert audience:

**Diving into the RDMA RXE Implementation**

Okay, so the prompt directs me to investigate `drivers/infiniband/sw/rxe/rxe_net.c`. This strongly suggests an interest in the software-based RDMA over Ethernet (RXE) implementation within the Linux kernel's Infiniband subsystem. The key here is the conditional compilation flag: `CONFIG_RDMA_RXE`. My immediate thought is, "Right, we're likely examining a section of code *specifically* enabled when RXE support is configured." This points to functionality, logic, and potential optimizations that are only relevant when using software-emulated RDMA over standard Ethernet, not hardware-accelerated RDMA. I’ll be looking for configuration-specific code blocks, initialization sequences, and any conditional branches or macros tied directly to `CONFIG_RDMA_RXE`. Knowing the context, I expect to see networking-related structures and functions interwoven with the core RDMA concepts of verbs, completion queues, and memory registration – all adapted for Ethernet's transport. I'll need to pay close attention to the interaction between the RXE layer and the generic network stack, particularly the handling of Ethernet frames, data encapsulation, and addressing.

32/2

2026/07/07 02:54

tool

grepper

Args:

{
  "Expression": "config RDMA_RXE",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/infiniband/sw/rxe/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/sw/rxe/Kconfig:2:config RDMA_RXE\ndrivers/infiniband/sw/rxe/Kconfig-3-\ttristate \"Software RDMA over Ethernet (RoCE) driver\"\n"
}

33/2

2026/07/07 02:55

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 32287
							output: 25
							thoughts: 26

Thoughts:

Here's my take on the thought process, summarized as you requested:

**Navigating the Netdevsim Landscape**

Okay, so we're diving into this `netdevsim` stuff. My initial thought is to zero in on a potential area of interest within the kernel source code. Specifically, let's start with `drivers/net/netdevsim/psp.c`. This seems like a reasonable place to begin, given the likely interactions involved. And, since we're dealing with netdevsim, I'm making a mental note to check the `CONFIG_NETDEVSIM` compile-time option to ensure it's enabled. That flag will be key to understanding whether this code path is even relevant to the current build configuration. It’s the usual sanity check before getting too deep, to avoid wasting time looking at irrelevant code.

34/2

2026/07/07 02:55

tool

grepper

Args:

{
  "Expression": "config NETDEVSIM",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=602=source \"drivers/net/hyperv/Kconfig\"\ndrivers/net/Kconfig-603-\ndrivers/net/Kconfig:604:config NETDEVSIM\ndrivers/net/Kconfig-605-\ttristate \"Simulated networking device\"\n"
}

35/2

2026/07/07 02:55

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 32604
							output: 22
							thoughts: 93

Thoughts:

Here's my thought process, as if I were considering this code:

**Navigating the PSP Driver Source**

Okay, so I need to track down something related to the PSP driver and its configuration. My initial instinct is to go straight to `drivers/net/psp/psp_main.c`, assuming it's a typical driver structure. But hold on, the directory structure in Linux can be a bit… flexible. Wait, is it `net/psp/psp_main.c`? Or even just `psp_main.c`? No, no, the diff I'm reviewing explicitly lists `net/psp/psp_main.c`. Good, got it. Now, the main question: is this PSP feature enabled via a `CONFIG_PSP` define? Time to verify that this configuration option exists within this file. Let's look for `CONFIG_PSP`.

36/2

2026/07/07 02:55

tool

grepper

Error:

no matches

Args:

{
  "Expression": "config PSP",
  "PathPrefix": ""
}

Results:

{
  "error": "no matches"
}

37/2

2026/07/07 02:55

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 32920
							output: 24
							thoughts: 33

Thoughts:

Here's my thought process, as if I were considering this code:

**Navigating the Network Stack**

Okay, so we're looking at `net/psp/psp_main.c`. My first move? I'm immediately thinking, "Where does this fit in the larger network picture?" Specifically, given the "psp" prefix, I need to understand what this component is all about. The easiest place to start for this kind of context is the configuration system. I'd head straight for either `net/psp/Kconfig` (assuming there's a specific configuration file for the PSP-related code) or, if that doesn't exist or doesn't provide enough top-level context, I'll check the parent directory's `net/Kconfig`. These are the configuration files that'll tell me if this is a standalone feature, a dependent module, or part of a larger, conditionally-compiled system. That's where the architectural overview usually lives. They'll tell me if this is a feature I might be able to disable or if it’s a dependency of another network component. Understanding those Kconfig files is going to be crucial to understanding the role of this `psp_main.c` file within the overall network stack.

38/2

2026/07/07 02:55

tool

grepper

Error:

no matches

Args:

{
  "Expression": "config PSP",
  "PathPrefix": "net/"
}

Results:

{
  "error": "no matches"
}

39/2

2026/07/07 02:55

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 33256
							output: 26
							thoughts: 23

Thoughts:

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating a Potentially Obscured Dependency**

Hmm, `PSP`... that term feels a bit incomplete, like it's a piece of a larger puzzle. Instead of jumping to conclusions, my first instinct is to see if `PSP` is a component *within* something more clearly defined. So, let's go straight to the source: the `net/psp/Makefile`. The makefile is usually the best place to find dependencies, build configurations, and, ideally, any context clues about what `PSP` actually refers to in this particular project. From there, I can begin to triangulate what `PSP` is, what it does, and how it fits into the overall architecture.

40/2

2026/07/07 02:56

tool

grepper

Args:

{
  "Expression": "psp",
  "PathPrefix": "net/psp/Makefile"
}

Results:

{
  "Output": "net/psp/Makefile-2-\nnet/psp/Makefile:3:obj-$(CONFIG_INET_PSP) += psp.o\nnet/psp/Makefile-4-\nnet/psp/Makefile:5:psp-y := psp_main.o psp_nl.o psp_sock.o psp-nl-gen.o\n"
}

41/2

2026/07/07 02:56

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 33561
							output: 25
							thoughts: 7

Thoughts:

Okay, here's my interpretation of that:

**My Initial Reaction to `CONFIG_INET_PSP`**

Right, `CONFIG_INET_PSP`. Instantly, my mind jumps to the relevant kernel configuration option. This is about Packet Scheduling, specifically for the "Priority Scheduling Protocol" within the Linux kernel's networking stack. I immediately consider the implications. Enabling this would introduce a mechanism to prioritize network traffic based on certain criteria, likely defined through traffic control rules (tc).

My immediate thought is, what are the use cases? Where would this be valuable? Are we talking about prioritizing latency-sensitive applications like VoIP or video conferencing? Or perhaps prioritizing control traffic in an industrial environment? What about differentiating between interactive and background traffic on the network? I also need to think about how this interacts with other queuing disciplines. Does PSP play nicely with things like HTB (Hierarchical Token Bucket), FQ_CODEL, or even the basic FIFO (First-In, First-Out) queuing?

I start to formulate questions. What is the overhead? Does enabling this significantly impact CPU utilization? Is it worth the complexity of setting up and maintaining the traffic control rules? What version of the kernel are we working with? PSP may have evolved or improved in more recent versions. And, is this an isolated configuration, or is it part of a larger network setup or system architecture? Understanding the context is crucial.

Ultimately, my assessment hinges on the specific needs of the network environment and the potential trade-offs between performance, complexity, and resource consumption. I need more information to form a conclusive judgment.

42/2

2026/07/07 02:57

tool

grepper

Args:

{
  "Expression": "config INET_PSP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/psp/Kconfig-4-#\nnet/psp/Kconfig:5:config INET_PSP\nnet/psp/Kconfig-6-\tbool \"PSP Security Protocol support\"\n"
}

43/2

2026/07/07 02:57

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 33977
							output: 38
							thoughts: 1164

Thoughts:

**Refining the Target for Fuzzing: UDP Offload and Tunneling**

Okay, so I'm thinking about how to best approach fuzzing around UDP-related network functionality, specifically focusing on areas that have seen recent changes. The goal is to maximize the chances of uncovering potential bugs introduced by these modifications. `INET_PSP` is the trigger, the thing I'm trying to validate.

First, I quickly scan the known hardware driver landscape. I mentally tick through common Intel drivers (`i40e`, `iavf`, `ice`, `idpf`), Marvell (`octeontx2`), Mellanox (`mlx5`), and others (`sfc`, `stmmac`). I don't need *every* single driver, but I do note the importance of including `NETDEVSIM`, a crucial software driver that I can readily test in a virtual environment. `RDMA_RXE`, a software RoCE driver, is also worth keeping in mind for completeness.

Next, I need to define the relevant configurations to be enabled in order to exercise the right parts of the code. I'll make sure to enable features like `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, `IP_VS`, `AMT`, `WIREGUARD`, `6LOWPAN_NHC_UDP`, `NF_NAT_SNMP_BASIC`, `NET_ACT_CSUM`, and especially `RDMA_RXE` and `NETDEVSIM` alongside `INET_PSP`.

Now, diving into the code, I head straight for the UDP offload paths: `net/ipv4/udp_offload.c` and `net/ipv6/udp_offload.c`. I have a shortlist of functions to look at: `__skb_udp_tunnel_segment`, `__udp_gso_segment_list`, `__udp_gso_segment`, `udp_gro_receive_segment`, `udp_gro_receive`, `udp_gro_complete_segment`, `udp_gro_complete`, `udp4_gro_complete`, and `udp6_gro_complete`.

From here, I'm forming my list of `FocusSymbols`. I start with: `__udp_gso_segment`, `udp_gro_receive`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `__skb_udp_tunnel_segment`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `skb_segment`, and `tso_build_hdr`.

But now I do a quick sanity check. `skb_segment` is called for *all* GSO packets. It's too generic and likely a very hot path. I don't want to get distracted by things that are only marginally changed. `udp_gro_receive` is in the same boat; very hot, but maybe not the best place to focus. We *want* to find new, or modified paths.

So, I re-evaluate. I think `__udp_gso_segment` is more promising, and also `udp_tunnel_xmit_skb` and `udp_tunnel6_xmit_skb` are good choices. `udp_gro_complete`, `udp4_gro_complete`, and `udp6_gro_complete` also look relevant.

I briefly glance at `udp_set_len_short` and `udp_get_len_short` in `include/linux/udp.h` – inline functions, so probably not the core of the problem. Then, I check `net/ipv4/udp.c` and `net/ipv6/udp.c`. `udp_send_skb`, `udp_v6_send_skb`, `udp_rcv`, and `udpv6_rcv` are all modified. They are also super hot paths. We'll avoid them here to avoid skewing our coverage, but we absolutely know that functional changes were introduced there.

In short, there is a clear target here; `WorthFuzzing` is definitely true.

So, my final refined list of `FocusSymbols` will be: `__udp_gso_segment`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `__skb_udp_tunnel_segment`, and `udp_gro_receive_segment`. This should get us where we want to be. I'll take a quick look at `udp_gro_receive_segment` in `

44/2

2026/07/07 02:57

tool

grepper

Args:

{
  "Expression": "udp_gro_receive_segment",
  "PathPrefix": "net/ipv4/udp_offload.c"
}

Results:

{
  "Output": "net/ipv4/udp_offload.c=631=static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,\n--\nnet/ipv4/udp_offload.c-692-#define UDP_GRO_CNT_MAX 64\nnet/ipv4/udp_offload.c:693:static struct sk_buff *udp_gro_receive_segment(struct list_head *head,\nnet/ipv4/udp_offload.c-694-\t\t\t\t\t       struct sk_buff *skb)\n--\nnet/ipv4/udp_offload.c=774=struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,\n--\nnet/ipv4/udp_offload.c-806-\t\t    (sk \u0026\u0026 udp_test_bit(GRO_ENABLED, sk)) || NAPI_GRO_CB(skb)-\u003eis_flist)\nnet/ipv4/udp_offload.c:807:\t\t\treturn call_gro_receive(udp_gro_receive_segment, head, skb);\nnet/ipv4/udp_offload.c-808-\n"
}

45/2

2026/07/07 02:57

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 36502
							output: 35
							thoughts: 62

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**UDP GRO and Tunneling Considerations**

Alright, looking at this, `udp_gro_receive_segment` seems like a solid starting point for investigation. My initial intuition is leading me there, and I want to confirm that suspicion.

I need to dive into the core FOu code next, specifically, `net/ipv4/fou_core.c` and `net/ipv6/fou6.c`. I'm particularly interested in the functions responsible for building the UDP headers, so I'll be looking closely at `fou_build_udp` (IPv4) and `fou6_build_udp` (IPv6). I need to understand how these functions interact with the GRO path, and if they're already taking the appropriate steps that I might be looking to replicate. Understanding their behavior is a prerequisite to making any changes.

46/2

2026/07/07 02:57

tool

grepper

Args:

{
  "Expression": "fou_build_udp",
  "PathPrefix": "net/ipv4/fou_core.c"
}

Results:

{
  "Output": "net/ipv4/fou_core.c=1027=EXPORT_SYMBOL(__gue_build_header);\n--\nnet/ipv4/fou_core.c-1030-\nnet/ipv4/fou_core.c:1031:static void fou_build_udp(struct sk_buff *skb, struct ip_tunnel_encap *e,\nnet/ipv4/fou_core.c-1032-\t\t\t  struct flowi4 *fl4, u8 *protocol, __be16 sport)\n--\nnet/ipv4/fou_core.c=1050=static int fou_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,\n--\nnet/ipv4/fou_core.c-1061-\nnet/ipv4/fou_core.c:1062:\tfou_build_udp(skb, e, fl4, protocol, sport);\nnet/ipv4/fou_core.c-1063-\n--\nnet/ipv4/fou_core.c=1067=static int gue_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,\n--\nnet/ipv4/fou_core.c-1078-\nnet/ipv4/fou_core.c:1079:\tfou_build_udp(skb, e, fl4, protocol, sport);\nnet/ipv4/fou_core.c-1080-\n"
}

47/2

2026/07/07 02:57

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 37167
							output: 37
							thoughts: 71

Thoughts:

Here's my thinking:

**UDP Encapsulation Strategy**

Okay, I'm trying to figure out the best approach for building UDP-encapsulated packets. Given the context, `fou_build_udp` and `fou6_build_udp` immediately jump out as strong possibilities, they are the obvious candidates.

Now, to refine my understanding, I need to see how these functions are implemented. I'll take a look at the ESP code; specifically, I need to investigate the interaction with UDP encapsulation within the ESP context. I'll start by checking the implementations of the relevant ESP output functions: `net/ipv4/esp4.c` and `net/ipv6/esp6.c`, looking for the relevant functions to build these UDP encapsulated packets, which I suspect are `esp_output_udp_encap` and `esp6_output_udp_encap`. This should give me the low-level details I need.

48/2

2026/07/07 02:58

tool

grepper

Args:

{
  "Expression": "esp_output_udp_encap",
  "PathPrefix": "net/ipv4/esp4.c"
}

Results:

{
  "Output": "net/ipv4/esp4.c=301=static void esp_output_done_esn(void *data, int err)\n--\nnet/ipv4/esp4.c-308-\nnet/ipv4/esp4.c:309:static struct ip_esp_hdr *esp_output_udp_encap(struct sk_buff *skb,\nnet/ipv4/esp4.c-310-\t\t\t\t\t       int encap_type,\n--\nnet/ipv4/esp4.c-329-\t/* For IPv4 ESP with UDP encapsulation, if xo is not null, the skb is in the crypto offload\nnet/ipv4/esp4.c:330:\t * data path, which means that esp_output_udp_encap is called outside of the XFRM stack.\nnet/ipv4/esp4.c-331-\t * In this case, the mac header doesn't point to the IPv4 protocol field, so don't set it.\n--\nnet/ipv4/esp4.c=376=static int esp_output_encap(struct xfrm_state *x, struct sk_buff *skb,\n--\nnet/ipv4/esp4.c-392-\tcase UDP_ENCAP_ESPINUDP:\nnet/ipv4/esp4.c:393:\t\tesph = esp_output_udp_encap(skb, encap_type, esp, sport, dport);\nnet/ipv4/esp4.c-394-\t\tbreak;\n"
}

49/2

2026/07/07 02:58

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 37859
							output: 41
							thoughts: 57

Thoughts:

Here's my thought process, as if I were considering this issue:

**Considering UDP Encapsulation Options**

Okay, so I'm looking at UDP encapsulation methods. Based on my experience, I think `esp_output_udp_encap` and `esp6_output_udp_encap` are strong contenders here. They're likely designed for the kind of encapsulation I need.

Just to be thorough, I should also check out `net/l2tp/l2tp_core.c`. Sometimes, similar functionality is buried in unexpected places. Specifically, I'll pay close attention to `l2tp_xmit_core`. It's possible there are relevant code snippets or architectural insights there that I might be able to leverage. I'll need to assess the applicability of what I find.

50/2

2026/07/07 02:58

tool

grepper

Args:

{
  "Expression": "l2tp_xmit_core",
  "PathPrefix": "net/l2tp/l2tp_core.c"
}

Results:

{
  "Output": "net/l2tp/l2tp_core.c=1209=static int l2tp_xmit_queue(struct l2tp_tunnel *tunnel, struct sk_buff *skb, struct flowi *fl)\n--\nnet/l2tp/l2tp_core.c-1224-\nnet/l2tp/l2tp_core.c:1225:static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, unsigned int *len)\nnet/l2tp/l2tp_core.c-1226-{\n--\nnet/l2tp/l2tp_core.c=1328=int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb)\n--\nnet/l2tp/l2tp_core.c-1332-\nnet/l2tp/l2tp_core.c:1333:\tret = l2tp_xmit_core(session, skb, \u0026len);\nnet/l2tp/l2tp_core.c-1334-\tif (ret == NET_XMIT_SUCCESS) {\n"
}

51/2

2026/07/07 02:58

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 38437
							output: 43
							thoughts: 48

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Initial Assessment: Transmission Candidate Analysis**

Right, let's see, based on what I know and experience, `l2tp_xmit_core` feels like a strong contender here. I think it's where I need to start. It just *feels* like the place to look for that bit of functionality, or at least a good reference point for the low-level transmission logic.

Now, let's double-check my gut feeling and see how this all intersects with something like `net/netfilter/ipvs/ip_vs_xmit.c`. Particularly interested in digging into how they handle encapsulation here, so let's check out `ipvs_gue_encap`. Always better to confirm and compare against a known, related module. I'll need to see how they're handling things.

52/2

2026/07/07 02:58

tool

grepper

Args:

{
  "Expression": "ipvs_gue_encap",
  "PathPrefix": "net/netfilter/ipvs/ip_vs_xmit.c"
}

Results:

{
  "Output": "net/netfilter/ipvs/ip_vs_xmit.c=1037=static int\nnet/netfilter/ipvs/ip_vs_xmit.c:1038:ipvs_gue_encap(struct net *net, struct sk_buff *skb,\nnet/netfilter/ipvs/ip_vs_xmit.c-1039-\t       struct ip_vs_conn *cp, __u8 *next_protocol)\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=1149=ip_vs_tunnel_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-1246-\nnet/netfilter/ipvs/ip_vs_xmit.c:1247:\t\tif (ipvs_gue_encap(net, skb, cp, \u0026next_protocol))\nnet/netfilter/ipvs/ip_vs_xmit.c-1248-\t\t\tgoto tx_error;\n--\nnet/netfilter/ipvs/ip_vs_xmit.c=1294=ip_vs_tunnel_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,\n--\nnet/netfilter/ipvs/ip_vs_xmit.c-1389-\nnet/netfilter/ipvs/ip_vs_xmit.c:1390:\t\tif (ipvs_gue_encap(net, skb, cp, \u0026next_protocol))\nnet/netfilter/ipvs/ip_vs_xmit.c-1391-\t\t\tgoto tx_error;\n"
}

53/2

2026/07/07 02:58

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 39148
							output: 34
							thoughts: 38

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Considering IPVS and TSO for Network Optimization**

Hmm, `ipvs_gue_encap`… that's got some potential. I'm thinking about network performance optimization, and tunneling is often a good area to examine. IPVS, especially with Generic UDP Encapsulation, that could be a significant player here.

Alright, let's dive deeper. I'm going to shift focus to `net/core/tso.c` now. This is where the core Transmission Segmentation Offload (TSO) functionality resides, crucial for handling large packets efficiently. Specifically, I need to check out `tso_build_hdr`. Understanding how the headers are constructed during TSO is key to identifying any bottlenecks or potential improvements related to IPVS encapsulation and how it interacts with TSO.

54/2

2026/07/07 02:59

tool

grepper

Args:

{
  "Expression": "tso_build_hdr",
  "PathPrefix": "net/core/tso.c"
}

Results:

{
  "Output": "net/core/tso.c-8-\nnet/core/tso.c:9:void tso_build_hdr(const struct sk_buff *skb, char *hdr, struct tso_t *tso,\nnet/core/tso.c-10-\t\t   int size, bool is_last)\n--\nnet/core/tso.c-45-}\nnet/core/tso.c:46:EXPORT_SYMBOL(tso_build_hdr);\nnet/core/tso.c-47-\n"
}

55/2

2026/07/07 02:59

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 39550
							output: 32
							thoughts: 35

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating a Potential Header Building Strategy**

Alright, given the context, `tso_build_hdr` looks like a strong starting point for the header construction. It's a natural candidate for this kind of operation. Now, to be thorough, I should check the implementation details, specifically how segmentation is handled within the kernel.

Let's dive into `net/core/skbuff.c`. I need to understand how the system manages the network buffers at the core level. Specifically, I'm thinking about how the system handles segmentation, so I want to understand what's in `skb_segment`. This should reveal some of the inner workings.

56/2

2026/07/07 02:59

tool

grepper

Args:

{
  "Expression": "skb_segment",
  "PathPrefix": "net/core/skbuff.c"
}

Results:

{
  "Output": "net/core/skbuff.c=4656=static inline skb_frag_t skb_head_frag_to_page_desc(struct sk_buff *frag_skb)\n--\nnet/core/skbuff.c-4667-\nnet/core/skbuff.c:4668:struct sk_buff *skb_segment_list(struct sk_buff *skb,\nnet/core/skbuff.c-4669-\t\t\t\t netdev_features_t features,\n--\nnet/core/skbuff.c-4759-}\nnet/core/skbuff.c:4760:EXPORT_SYMBOL_GPL(skb_segment_list);\nnet/core/skbuff.c-4761-\nnet/core/skbuff.c-4762-/**\nnet/core/skbuff.c:4763: *\tskb_segment - Perform protocol segmentation on skb.\nnet/core/skbuff.c-4764- *\t@head_skb: buffer to segment\n--\nnet/core/skbuff.c-4770- */\nnet/core/skbuff.c:4771:struct sk_buff *skb_segment(struct sk_buff *head_skb,\nnet/core/skbuff.c-4772-\t\t\t    netdev_features_t features)\n--\nnet/core/skbuff.c-5027-\t\t\t\tnet_warn_ratelimited(\nnet/core/skbuff.c:5028:\t\t\t\t\t\"skb_segment: too many frags: %u %u\\n\",\nnet/core/skbuff.c-5029-\t\t\t\t\tpos, mss);\n--\nnet/core/skbuff.c-5123-}\nnet/core/skbuff.c:5124:EXPORT_SYMBOL_GPL(skb_segment);\nnet/core/skbuff.c-5125-\n"
}

57/2

2026/07/07 02:59

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 40261
							output: 38
							thoughts: 39

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**UDP Segmentation Exploration**

Alright, based on the problem I'm tackling, `skb_segment` is looking like a pretty solid starting point. It's the standard function for packet segmentation in the kernel, and it's always a good idea to see if the core utilities can handle the issue.

Let's dive into the UDP offload implementation. I'll need to reference `net/ipv4/udp_offload.c` to understand how the UDP stack handles segmentation, especially for GSO. I'm particularly interested in that `__udp_gso_segment` function. I anticipate it might be the core logic for the UDP specific segmentation. I'll need to thoroughly examine its arguments, and how it interacts with other networking layers.

58/2

2026/07/07 02:59

tool

grepper

Args:

{
  "Expression": "__udp_gso_segment",
  "PathPrefix": "net/ipv4/udp_offload.c"
}

Results:

{
  "Output": "net/ipv4/udp_offload.c=429=static struct sk_buff *__udpv6_gso_segment_list_csum(struct sk_buff *segs)\n--\nnet/ipv4/udp_offload.c-460-\nnet/ipv4/udp_offload.c:461:static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,\nnet/ipv4/udp_offload.c-462-\t\t\t\t\t      netdev_features_t features,\n--\nnet/ipv4/udp_offload.c-478-\nnet/ipv4/udp_offload.c:479:struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,\nnet/ipv4/udp_offload.c-480-\t\t\t\t  netdev_features_t features, bool is_ipv6)\n--\nnet/ipv4/udp_offload.c-517-\t\t    !(skb_shinfo(gso_skb)-\u003egso_type \u0026 SKB_GSO_DODGY))\nnet/ipv4/udp_offload.c:518:\t\t\treturn __udp_gso_segment_list(gso_skb, features, is_ipv6);\nnet/ipv4/udp_offload.c-519-\n--\nnet/ipv4/udp_offload.c=631=static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,\n--\nnet/ipv4/udp_offload.c-653-\tif (skb_shinfo(skb)-\u003egso_type \u0026 SKB_GSO_UDP_L4)\nnet/ipv4/udp_offload.c:654:\t\treturn __udp_gso_segment(skb, features, false);\nnet/ipv4/udp_offload.c-655-\n"
}

59/2

2026/07/07 02:59

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 41005
							output: 38
							thoughts: 53

Thoughts:

Okay, here's my take on those Linux kernel function names and their potential relevance, as if I'm processing them myself:

**UDP Offload Function Investigation**

Alright, looking at this code, my initial gut reaction is that `__udp_gso_segment` and `__udp_gso_segment_list` are strong possibilities for what I'm interested in. The naming strongly implies they're involved in Generic Segmentation Offload (GSO) specifically for UDP. That's exactly the area I need to understand better for this networking optimization I'm working on.

Let's dig in a bit further to confirm that suspicion. The next logical step would be to see how these functions are being used. Specifically, I'll check in `net/ipv6/udp_offload.c`. I expect to find some of the IPv6 UDP offload logic there, which should give me context for understanding the GSO functions. I see `udp6_ufo_fragment`, which is a key part of the UFO/GSO path and what I expect to be near related code.

60/2

2026/07/07 02:59

tool

grepper

Args:

{
  "Expression": "udp6_ufo_fragment",
  "PathPrefix": "net/ipv6/udp_offload.c"
}

Results:

{
  "Output": "net/ipv6/udp_offload.c-18-\nnet/ipv6/udp_offload.c:19:static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,\nnet/ipv6/udp_offload.c-20-\t\t\t\t\t netdev_features_t features)\n--\nnet/ipv6/udp_offload.c=191=int __init udpv6_offload_init(void)\n--\nnet/ipv6/udp_offload.c-194-\t\t.callbacks = {\nnet/ipv6/udp_offload.c:195:\t\t\t.gso_segment\t=\tudp6_ufo_fragment,\nnet/ipv6/udp_offload.c-196-\t\t\t.gro_receive\t=\tudp6_gro_receive,\n"
}

61/2

2026/07/07 02:59

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 41543
							output: 41
							thoughts: 50

Thoughts:

Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person:

**UDP Fragmentation & Generic Segmentation Offload - Delving into the Kernel**

Right, so `udp6_ufo_fragment` is calling `__udp_gso_segment`. That immediately flags something interesting. I need to understand how the Userland Fragmentation Offload (UFO) is interacting with Generic Segmentation Offload (GSO) for UDPv6.  The potential performance implications are obvious; any inefficiencies here would be multiplied, especially at scale.

My next stop is definitely `net/ipv4/udp_tunnel_core.c`. I need to understand the tunneling aspects of this. That will likely lead me to `udp_tunnel_xmit_skb`. I'm expecting to find the key logic there around packet construction and segmentation. I need to see how these functions coordinate to handle fragmentation in the context of tunnels. I need to understand the interaction between the UFO, GSO, and any tunnel specific optimizations. I'm looking for any hints about potential packet size limitations or how the system handles the complexities of nested headers.

62/2

2026/07/07 03:00

tool

grepper

Args:

{
  "Expression": "udp_tunnel_xmit_skb",
  "PathPrefix": "net/ipv4/udp_tunnel_core.c"
}

Results:

{
  "Output": "net/ipv4/udp_tunnel_core.c=166=EXPORT_SYMBOL_GPL(udp_tunnel_notify_del_rx_port);\nnet/ipv4/udp_tunnel_core.c-167-\nnet/ipv4/udp_tunnel_core.c:168:void udp_tunnel_xmit_skb(struct rtable *rt, struct sock *sk, struct sk_buff *skb,\nnet/ipv4/udp_tunnel_core.c-169-\t\t\t __be32 src, __be32 dst, __u8 tos, __u8 ttl,\n--\nnet/ipv4/udp_tunnel_core.c-189-}\nnet/ipv4/udp_tunnel_core.c:190:EXPORT_SYMBOL_GPL(udp_tunnel_xmit_skb);\nnet/ipv4/udp_tunnel_core.c-191-\n"
}

63/2

2026/07/07 03:00

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 42105
							output: 43
							thoughts: 49

Thoughts:

Okay, here's my take on those thoughts, framed as my own mental process, given my expertise:

**Examining Potential Tunneling Transmission Candidates**

Alright, looking at potential candidates for this transmission task, `udp_tunnel_xmit_skb` definitely piques my interest. It's a solid contender given the naming convention and likely function. Now, let's drill down and see if my suspicion holds.

The next logical step is to dive into the IPv6 UDP tunneling code. I'll check `net/ipv6/ip6_udp_tunnel.c`. Specifically, I'm going to examine the function `udp_tunnel6_xmit_skb`. This seems like a strong bet, given that we're dealing with UDP tunneling and IPv6. It's likely involved in transmitting the SKB. Let's see what the implementation looks like and how it handles the details. It probably handles the encapsulation and header construction. I suspect there will be checks for tunnel parameters and some clever optimizations.

64/2

2026/07/07 03:00

tool

grepper

Args:

{
  "Expression": "udp_tunnel6_xmit_skb",
  "PathPrefix": "net/ipv6/ip6_udp_tunnel.c"
}

Results:

{
  "Output": "net/ipv6/ip6_udp_tunnel.c=75=EXPORT_SYMBOL_GPL(udp_sock_create6);\nnet/ipv6/ip6_udp_tunnel.c-76-\nnet/ipv6/ip6_udp_tunnel.c:77:void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,\nnet/ipv6/ip6_udp_tunnel.c-78-\t\t\t  struct sk_buff *skb,\n--\nnet/ipv6/ip6_udp_tunnel.c-113-}\nnet/ipv6/ip6_udp_tunnel.c:114:EXPORT_SYMBOL_GPL(udp_tunnel6_xmit_skb);\nnet/ipv6/ip6_udp_tunnel.c-115-\n"
}

65/2

2026/07/07 03:00

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 42623
							output: 40
							thoughts: 47

Thoughts:

Okay, here's my take on those thoughts, framed as my own reasoning:

**Candidate Identified: UDP Tunnel Offload**

Alright, based on what I'm looking at, `udp_tunnel6_xmit_skb` seems like a strong contender for the area I need to investigate further. It's a key function in handling these packets, I need to understand its role. I need to understand this part of the flow.

Now, let's dive into the code itself. I'll need to locate the implementation, which likely lives under `net/ipv4/`. I'm going to want to focus on offload capabilities, so let's check `udp_offload.c` directly. My suspicion is that this is the correct place to begin the analysis.

And yes, here it is, `__skb_udp_tunnel_segment`. Bingo! This looks like the core function involved in breaking down the SKB for tunneling. This is exactly what I was hoping to find, the segmentation logic is in this area, that's what I needed. Now, I can really start to get into the details of the tunneling implementation.

66/2

2026/07/07 03:00

tool

grepper

Args:

{
  "Expression": "__skb_udp_tunnel_segment",
  "PathPrefix": "net/ipv4/udp_offload.c"
}

Results:

{
  "Output": "net/ipv4/udp_offload.c=163=static struct sk_buff *udp_tunnel_gro_rcv(struct sock *sk,\n--\nnet/ipv4/udp_offload.c-171-\nnet/ipv4/udp_offload.c:172:static struct sk_buff *__skb_udp_tunnel_segment(struct sk_buff *skb,\nnet/ipv4/udp_offload.c-173-\tnetdev_features_t features,\n--\nnet/ipv4/udp_offload.c=309=struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,\n--\nnet/ipv4/udp_offload.c-337-\nnet/ipv4/udp_offload.c:338:\tsegs = __skb_udp_tunnel_segment(skb, features, gso_inner_segment,\nnet/ipv4/udp_offload.c-339-\t\t\t\t\tprotocol, is_ipv6);\n"
}

67/2

2026/07/07 03:00

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 43219
							output: 36
							thoughts: 42

Thoughts:

Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise:

**Examining UDP Offload Possibilities**

Alright, based on the context, I think `__skb_udp_tunnel_segment` looks like a promising function to investigate further. It's often involved in handling UDP traffic, especially in tunneling scenarios, which is precisely what I'm looking at. Let's delve into the actual implementation. I'll head over to `net/ipv4/udp_offload.c` and take a closer look at the source code there. I suspect the function `udp_gro_complete` is going to be relevant as well. We'll examine that and its interactions as well.

68/2

2026/07/07 03:01

tool

grepper

Args:

{
  "Expression": "udp_gro_complete",
  "PathPrefix": "net/ipv4/udp_offload.c"
}

Results:

{
  "Output": "net/ipv4/udp_offload.c=868=struct sk_buff *udp4_gro_receive(struct list_head *head, struct sk_buff *skb)\n--\nnet/ipv4/udp_offload.c-898-\nnet/ipv4/udp_offload.c:899:static int udp_gro_complete_segment(struct sk_buff *skb)\nnet/ipv4/udp_offload.c-900-{\n--\nnet/ipv4/udp_offload.c-915-\nnet/ipv4/udp_offload.c:916:int udp_gro_complete(struct sk_buff *skb, int nhoff,\nnet/ipv4/udp_offload.c-917-\t\t     udp_lookup_t lookup)\n--\nnet/ipv4/udp_offload.c-943-\t} else {\nnet/ipv4/udp_offload.c:944:\t\terr = udp_gro_complete_segment(skb);\nnet/ipv4/udp_offload.c-945-\t}\n--\nnet/ipv4/udp_offload.c=953=INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)\n--\nnet/ipv4/udp_offload.c-974-\nnet/ipv4/udp_offload.c:975:\treturn udp_gro_complete(skb, nhoff, udp4_lib_lookup_skb);\nnet/ipv4/udp_offload.c-976-}\n"
}

69/2

2026/07/07 03:01

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 43858
							output: 37
							thoughts: 39

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**Considering UDP GRO Completion**

Right, let's zero in on this GRO completion process for UDP. `udp_gro_complete` seems like a prime spot to start digging. It just *feels* right. Time to dive into the codebase. I need to get a clear picture of how this is actually implemented.

Let me take a look at the code in `net/ipv6/udp_offload.c`, and more specifically, `udp6_gro_complete`. That should give me the lowdown on the IPv6 implementation, which usually provides a solid foundation for understanding the broader UDP GRO handling. With my experience, I think this should be a productive avenue.

70/2

2026/07/07 03:02

tool

grepper

Args:

{
  "Expression": "udp6_gro_complete",
  "PathPrefix": "net/ipv6/udp_offload.c"
}

Results:

{
  "Output": "net/ipv6/udp_offload.c=134=struct sk_buff *udp6_gro_receive(struct list_head *head, struct sk_buff *skb)\n--\nnet/ipv6/udp_offload.c-165-\nnet/ipv6/udp_offload.c:166:int udp6_gro_complete(struct sk_buff *skb, int nhoff)\nnet/ipv6/udp_offload.c-167-{\n--\nnet/ipv6/udp_offload.c=191=int __init udpv6_offload_init(void)\n--\nnet/ipv6/udp_offload.c-196-\t\t\t.gro_receive\t=\tudp6_gro_receive,\nnet/ipv6/udp_offload.c:197:\t\t\t.gro_complete\t=\tudp6_gro_complete,\nnet/ipv6/udp_offload.c-198-\t\t},\n"
}

71/2

2026/07/07 03:02

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 44340
							output: 32
							thoughts: 35

Thoughts:

Okay, here's my take on those thoughts, tailored for an expert audience:

**Considering Potential GRO Completion Candidates**

Alright, let's zero in. Thinking about completing GRO (Generic Receive Offload), and my instincts are pointing towards `udp6_gro_complete`. It feels right, but I need to confirm. My immediate next step is to examine the source. Let's delve into `net/core/skbuff.c`. I'm especially interested in understanding how the segmentation and reassembly process is handled at a low level. More specifically, I should be looking at `skb_segment` within that file, as it’s critical for understanding how packets are broken down and put back together. This function will be key to understanding the context of my candidate for GRO completion.

72/2

2026/07/07 03:03

tool

grepper

Args:

{
  "Expression": "skb_segment",
  "PathPrefix": "net/core/skbuff.c"
}

Results:

{
  "Output": "net/core/skbuff.c=4656=static inline skb_frag_t skb_head_frag_to_page_desc(struct sk_buff *frag_skb)\n--\nnet/core/skbuff.c-4667-\nnet/core/skbuff.c:4668:struct sk_buff *skb_segment_list(struct sk_buff *skb,\nnet/core/skbuff.c-4669-\t\t\t\t netdev_features_t features,\n--\nnet/core/skbuff.c-4759-}\nnet/core/skbuff.c:4760:EXPORT_SYMBOL_GPL(skb_segment_list);\nnet/core/skbuff.c-4761-\nnet/core/skbuff.c-4762-/**\nnet/core/skbuff.c:4763: *\tskb_segment - Perform protocol segmentation on skb.\nnet/core/skbuff.c-4764- *\t@head_skb: buffer to segment\n--\nnet/core/skbuff.c-4770- */\nnet/core/skbuff.c:4771:struct sk_buff *skb_segment(struct sk_buff *head_skb,\nnet/core/skbuff.c-4772-\t\t\t    netdev_features_t features)\n--\nnet/core/skbuff.c-5027-\t\t\t\tnet_warn_ratelimited(\nnet/core/skbuff.c:5028:\t\t\t\t\t\"skb_segment: too many frags: %u %u\\n\",\nnet/core/skbuff.c-5029-\t\t\t\t\tpos, mss);\n--\nnet/core/skbuff.c-5123-}\nnet/core/skbuff.c:5124:EXPORT_SYMBOL_GPL(skb_segment);\nnet/core/skbuff.c-5125-\n"
}

73/2

2026/07/07 03:03

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 45057
							output: 34
							thoughts: 105

Thoughts:

**Considering SKB Segmentation for Optimization**

Okay, so I'm evaluating where to optimize, and `skb_segment` is looking like a promising starting point. I need to dive deeper into the code to really understand the impact.

First, let's take a look at `net/ipv4/udp.c`. I see modifications have been made to both `udp_rcv` and `udpv6_rcv`, and also to `udp_send_skb` and `udp_v6_send_skb`. Hmm, these are definitely hot paths – the core of UDP reception and transmission. Given the potential for performance regression, I need to be *very* careful if I make modifications here. I think I'll aim to avoid touching those functions if possible.

Now, let's switch gears and investigate `net/core/tso.c`. I'm curious about the specific use of `tso_build_hdr`. Understanding this part is crucial.

74/2

2026/07/07 03:03

tool

grepper

Args:

{
  "Expression": "tso_build_hdr",
  "PathPrefix": "net/core/tso.c"
}

Results:

{
  "Output": "net/core/tso.c-8-\nnet/core/tso.c:9:void tso_build_hdr(const struct sk_buff *skb, char *hdr, struct tso_t *tso,\nnet/core/tso.c-10-\t\t   int size, bool is_last)\n--\nnet/core/tso.c-45-}\nnet/core/tso.c:46:EXPORT_SYMBOL(tso_build_hdr);\nnet/core/tso.c-47-\n"
}

75/2

2026/07/07 03:03

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 45547
							output: 32
							thoughts: 35

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Considering Potential Candidates**

Alright, based on the context I'm processing, `tso_build_hdr` is looking like a solid lead. My initial instinct is that it's likely involved in the construction of headers, and that's precisely where I need to focus.

To confirm and delve deeper, the next logical step is to examine the `drivers/net/geneve.c` file. Geneve, as an encapsulation protocol, is a likely place where header construction and manipulation would occur. Specifically, I'll pay close attention to the `geneve_setup` function within that file. This function name strongly implies it has something to do with initializing or configuring the Geneve protocol, which likely involves setting up or modifying header information. I'll need to see how it interacts with the underlying datapath and whether it directly calls into a function like `tso_build_hdr`. Let's see if this lines up.

76/2

2026/07/07 03:04

tool

grepper

Args:

{
  "Expression": "geneve_setup",
  "PathPrefix": "drivers/net/geneve.c"
}

Results:

{
  "Output": "drivers/net/geneve.c=1693=static void geneve_offload_rx_ports(struct net_device *dev, bool push)\n--\ndrivers/net/geneve.c-1712-/* Initialize the device structure. */\ndrivers/net/geneve.c:1713:static void geneve_setup(struct net_device *dev)\ndrivers/net/geneve.c-1714-{\n--\ndrivers/net/geneve.c=2531=static struct rtnl_link_ops geneve_link_ops __read_mostly = {\n--\ndrivers/net/geneve.c-2535-\t.priv_size\t= sizeof(struct geneve_dev),\ndrivers/net/geneve.c:2536:\t.setup\t\t= geneve_setup,\ndrivers/net/geneve.c-2537-\t.validate\t= geneve_validate,\n"
}

77/2

2026/07/07 03:04

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 46068
							output: 37
							thoughts: 46

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Initial Assessment of Function and Code Location**

Right, so `geneve_setup` isn't a data path function, it's pretty clear it's just involved with the initial setup or configuration, which I kind of figured, but it's good to confirm. It won't be involved in the actual forwarding of data.

Given that, I need to look for where the actual VXLAN data path logic resides. My gut feeling tells me the `drivers/net` directory is a likely candidate, and more specifically I'm betting it's in a file named something like `vxlan_core.c`. Let's confirm that hypothesis, so I'll be looking into `drivers/net/vxlan/vxlan_core.c`.

Okay, the most obvious function name to look at is `vxlan_setup`, which is probably the critical entry point to examine within that file for the relevant data path operations. Let's see what that function does.

78/2

2026/07/07 03:04

tool

grepper

Args:

{
  "Expression": "vxlan_setup",
  "PathPrefix": "drivers/net/vxlan/vxlan_core.c"
}

Results:

{
  "Output": "drivers/net/vxlan/vxlan_core.c=3319=static void vxlan_offload_rx_ports(struct net_device *dev, bool push)\n--\ndrivers/net/vxlan/vxlan_core.c-3345-/* Initialize the device structure. */\ndrivers/net/vxlan/vxlan_core.c:3346:static void vxlan_setup(struct net_device *dev)\ndrivers/net/vxlan/vxlan_core.c-3347-{\n--\ndrivers/net/vxlan/vxlan_core.c=4678=static struct rtnl_link_ops vxlan_link_ops __read_mostly = {\n--\ndrivers/net/vxlan/vxlan_core.c-4682-\t.priv_size\t= sizeof(struct vxlan_dev),\ndrivers/net/vxlan/vxlan_core.c:4683:\t.setup\t\t= vxlan_setup,\ndrivers/net/vxlan/vxlan_core.c-4684-\t.validate\t= vxlan_validate,\n"
}

79/2

2026/07/07 03:04

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 46651
							output: 40
							thoughts: 43

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Analyzing VXLAN Setup in Routing Context**

Right, `vxlan_setup` immediately doesn't seem like it's a core data path function. That suggests it's likely involved in control plane configuration or perhaps ancillary tasks rather than the actual forwarding of VXLAN packets themselves. I need to dig into the routing context to understand this better. My next move is to check `net/ipv4/route.c`. The intention is to determine how the route resolution and packet crafting are handled within the IPv4 routing subsystem. Specifically, I'm going to examine `inet_rtm_getroute_build_skb`, as that's the likely location for how the system handles the routing decisions and packet creation for outbound traffic. I want to see how VXLAN is integrated, if at all, at that stage.

80/2

2026/07/07 03:04

tool

grepper

Args:

{
  "Expression": "inet_rtm_getroute_build_skb",
  "PathPrefix": "net/ipv4/route.c"
}

Results:

{
  "Output": "net/ipv4/route.c=3127=int fib_dump_info_fnhe(struct sk_buff *skb, struct netlink_callback *cb,\n--\nnet/ipv4/route.c-3156-\nnet/ipv4/route.c:3157:static struct sk_buff *inet_rtm_getroute_build_skb(__be32 src, __be32 dst,\nnet/ipv4/route.c-3158-\t\t\t\t\t\t   u8 ip_proto, __be16 sport,\n--\nnet/ipv4/route.c=3287=static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,\n--\nnet/ipv4/route.c-3335-\nnet/ipv4/route.c:3336:\tskb = inet_rtm_getroute_build_skb(src, dst, ip_proto, sport, dport);\nnet/ipv4/route.c-3337-\tif (!skb)\n"
}

81/2

2026/07/07 03:04

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 47196
							output: 37
							thoughts: 55

Thoughts:

Here's my take on the thought process, as if it were my own:

**Investigating Network Route Table Modification**

Okay, so I need to figure out a good starting point for examining this network route table modification. My initial instinct is that `inet_rtm_getroute_build_skb` looks like a promising function to dig into. That feels like a logical candidate, given its name.

Now, let's see... where's the most likely place to find related code? I'll check `net/ipv4/ipconfig.c`. That file usually holds the IP configuration and possibly the route-related interactions I'm after.

Hmm... after a quick scan of `ipconfig.c` I see `ic_bootp_send_if` and `ic_bootp_recv`. Might be helpful if those are used to set the initial routes. Let me keep those in mind as I search.

82/2

2026/07/07 03:04

tool

grepper

Args:

{
  "Expression": "ic_bootp_send_if",
  "PathPrefix": "net/ipv4/ipconfig.c"
}

Results:

{
  "Output": "net/ipv4/ipconfig.c=809=static inline void __init ic_bootp_cleanup(void)\n--\nnet/ipv4/ipconfig.c-817- */\nnet/ipv4/ipconfig.c:818:static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies_diff)\nnet/ipv4/ipconfig.c-819-{\n--\nnet/ipv4/ipconfig.c=1187=static int __init ic_dynamic(void)\n--\nnet/ipv4/ipconfig.c-1251-\t\tif (do_bootp \u0026\u0026 (d-\u003eable \u0026 IC_BOOTP))\nnet/ipv4/ipconfig.c:1252:\t\t\tic_bootp_send_if(d, jiffies - start_jiffies);\nnet/ipv4/ipconfig.c-1253-#endif\n"
}

83/2

2026/07/07 03:04

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 47723
							output: 34
							thoughts: 65

Thoughts:

Here's my summary, as though I'm thinking through this process:

**Fuzzing BOOTP: Initial Assessment**

Okay, so I'm looking at this code with the goal of fuzzing the BOOTP implementation. Right off the bat, `ic_bootp_send_if` and `ic_bootp_recv` are flagged as `__init` functions. That's not ideal.  `__init` means they're likely only called during the initial system setup or module loading, making them less interesting targets for ongoing, runtime fuzzing. I need to find something that's active throughout the network stack's operation.

Let's pivot. Since BOOTP is about building packets, I'll shift focus to how these packets are constructed at a lower level. My hunch is that I'll find potential fuzzing candidates in the packet generation routines. I'm going to check out `net/core/pktgen.c` now. Hopefully I can find some candidate functions there, and specifically I'm going to examine `fill_packet_ipv4` and `fill_packet_ipv6`. Those are the prime candidates.

84/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "fill_packet_ipv4",
  "PathPrefix": "net/core/pktgen.c"
}

Results:

{
  "Output": "net/core/pktgen.c=2900=static struct sk_buff *pktgen_alloc_skb(struct net_device *dev,\n--\nnet/core/pktgen.c-2926-\nnet/core/pktgen.c:2927:static struct sk_buff *fill_packet_ipv4(struct net_device *odev,\nnet/core/pktgen.c-2928-\t\t\t\t\tstruct pktgen_dev *pkt_dev)\n--\nnet/core/pktgen.c=3185=static struct sk_buff *fill_packet(struct net_device *odev,\n--\nnet/core/pktgen.c-3190-\telse\nnet/core/pktgen.c:3191:\t\treturn fill_packet_ipv4(odev, pkt_dev);\nnet/core/pktgen.c-3192-}\n"
}

85/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 48295
							output: 32
							thoughts: 58

Thoughts:

Here's my summary, as though I'm thinking through this process:

**Network Packet Construction Candidates**

Okay, so I'm looking at packet construction methods, and right off the bat, `fill_packet_ipv4` and `fill_packet_ipv6` seem like solid starting points. They are pretty generic, so they are a common point for building on and can be relevant across a few different scenarios, so it's worth checking them out.

Now, let's pivot and see what we have in `drivers/net/amt.c`. I have a feeling the AMT (Automatic Multicast Tunneling) code might offer some useful building blocks or, at the very least, insight into how they've handled similar packet construction or modification tasks within the kernel. Let's see... looking at the function names: `amt_send_discovery`, `amt_send_request`, and `amt_send_advertisement`. Those all sound like they're directly related to specific packet types, so they are likely to contain examples of constructing and populating fields. I'll need to check the implementations to determine their suitability, but I'm thinking these functions will offer something useful for the task at hand.

86/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "amt_send_discovery",
  "PathPrefix": "drivers/net/amt.c"
}

Results:

{
  "Output": "drivers/net/amt.c=605=static void amt_update_relay_status(struct amt_tunnel_list *tunnel,\n--\ndrivers/net/amt.c-612-\ndrivers/net/amt.c:613:static void amt_send_discovery(struct amt_dev *amt)\ndrivers/net/amt.c-614-{\n--\ndrivers/net/amt.c=932=static void amt_event_send_discovery(struct amt_dev *amt)\n--\ndrivers/net/amt.c-937-\ndrivers/net/amt.c:938:\tamt_send_discovery(amt);\ndrivers/net/amt.c-939-out:\n"
}

87/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 48826
							output: 31
							thoughts: 47

Thoughts:

Okay, here's my take on those initial thoughts, expressed from a first-person perspective, assuming I'm already deep in the weeds of network driver investigation:

**My Initial Assessment**

Alright, given the context, I think we're on the right track with `amt_send_discovery`, `amt_send_request`, and `amt_send_advertisement`. They're the obvious starting points when considering the network protocols involved in this problem, likely related to Automated Management Tunneling (AMT). But, before I get too far down that path, let's just make sure, let's not assume, there might be a more likely candidate based on context.

Let me take a look at `drivers/net/netconsole.c`. It's a low-level network console driver, and the name "netconsole" itself suggests this could very well be a relevant place. It would make sense if we're dealing with something related to debug or management interfaces. Ah yes, and I see `push_udp` in there, which likely makes it an excellent fit for AMT functions or any other similar UDP-based network functions.

88/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "push_udp",
  "PathPrefix": "drivers/net/netconsole.c"
}

Results:

{
  "Output": "drivers/net/netconsole.c=1757=static void netpoll_udp_checksum(struct netpoll *np, struct sk_buff *skb,\n--\ndrivers/net/netconsole.c-1781-\ndrivers/net/netconsole.c:1782:static void push_udp(struct netpoll *np, struct sk_buff *skb, int len)\ndrivers/net/netconsole.c-1783-{\n--\ndrivers/net/netconsole.c=1864=static int netpoll_send_udp(struct netpoll *np, const char *msg, int len)\n--\ndrivers/net/netconsole.c-1887-\ndrivers/net/netconsole.c:1888:\tpush_udp(np, skb, len);\ndrivers/net/netconsole.c-1889-\tif (np-\u003eipv6)\n"
}

89/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 49372
							output: 42
							thoughts: 42

Thoughts:

Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise:

**Examining the UDP Traffic Flow**

Right, `push_udp` is a solid starting point for investigating this. Seems like a natural candidate for the part of the code I need to scrutinize. Now, let's dive into the kernel source, specifically the network device simulation driver. I'll go straight to `drivers/net/netdevsim/dev.c`. I need to understand how the simulated network devices interact and handle packets. My hunch is that this is where I'll find the relevant packet manipulation, or perhaps the point where a simulation artifact is occurring. Let me look at the `nsim_dev_trap_skb_build` function. I have to see how it constructs the simulated SKBs for traffic. It is likely the place where the UDP packet is being manipulated.

90/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "nsim_dev_trap_skb_build",
  "PathPrefix": "drivers/net/netdevsim/dev.c"
}

Results:

{
  "Output": "drivers/net/netdevsim/dev.c=790=static const struct devlink_trap nsim_traps_arr[] = {\n--\ndrivers/net/netdevsim/dev.c-810-\ndrivers/net/netdevsim/dev.c:811:static struct sk_buff *nsim_dev_trap_skb_build(void)\ndrivers/net/netdevsim/dev.c-812-{\n--\ndrivers/net/netdevsim/dev.c=853=static void nsim_dev_trap_report(struct nsim_dev_port *nsim_dev_port)\n--\ndrivers/net/netdevsim/dev.c-875-\ndrivers/net/netdevsim/dev.c:876:\t\tskb = nsim_dev_trap_skb_build();\ndrivers/net/netdevsim/dev.c-877-\t\tif (!skb)\n"
}

91/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 49886
							output: 44
							thoughts: 52

Thoughts:

Okay, here's my interpretation of those thoughts, crafted with the understanding that I'm discussing this with a fellow expert:

**Investigating SKB Construction within the Netdevsim Driver**

Alright, I'm thinking that `nsim_dev_trap_skb_build` is a solid starting point for our investigation. It seems like it's a prime candidate for the SKB construction logic we're interested in. Given its name, it probably is responsible for how the SKB is built within the context of packet trapping or interception.

Let's drill down and confirm that suspicion by inspecting `drivers/net/netdevsim/psample.c`. I'm going to look specifically at how it constructs the SKB. Specifically, I'll be looking for `nsim_dev_psample_skb_build`. This looks like a promising function to examine, as it strongly suggests packet sampling within Netdevsim. Understanding how this particular function builds the SKB could illuminate the broader picture and reveal critical details about the process, which is important.

92/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "nsim_dev_psample_skb_build",
  "PathPrefix": "drivers/net/netdevsim/psample.c"
}

Results:

{
  "Output": "drivers/net/netdevsim/psample.c=23=struct nsim_dev_psample {\n--\ndrivers/net/netdevsim/psample.c-37-\ndrivers/net/netdevsim/psample.c:38:static struct sk_buff *nsim_dev_psample_skb_build(void)\ndrivers/net/netdevsim/psample.c-39-{\n--\ndrivers/net/netdevsim/psample.c=111=static void nsim_dev_psample_report_work(struct work_struct *work)\n--\ndrivers/net/netdevsim/psample.c-119-\ndrivers/net/netdevsim/psample.c:120:\tskb = nsim_dev_psample_skb_build();\ndrivers/net/netdevsim/psample.c-121-\tif (!skb)\n"
}

93/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 50439
							output: 37
							thoughts: 46

Thoughts:

Okay, here's my interpretation of those thoughts, crafted with the perspective of someone knowledgeable in network simulation and kernel code:

**Thinking Through a Network Packet Simulation Module**

Alright, based on the function name, `nsim_dev_psample_skb_build` looks like a strong starting point. It suggests that this is where the packet sampling and SKB (Socket Buffer) construction for the network simulation device is likely handled. Good candidate for inspection.

Now, where's the actual implementation? The logical place to start is the `drivers/net/netdevsim/` directory, especially the `psp.c` file which likely pertains to packet sampling or processing. Let's dig into that file. Specifically, I should be looking at the `nsim_do_psp` function. That name sounds like the core of the packet sampling/processing logic. I'm guessing that's where the heart of this functionality resides and where I will want to focus my attention. It could be the gateway to understanding how simulated packets are generated and handled within this network simulation environment.

94/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "nsim_do_psp",
  "PathPrefix": "drivers/net/netdevsim/psp.c"
}

Results:

{
  "Output": "drivers/net/netdevsim/psp.c=17=enum skb_drop_reason\ndrivers/net/netdevsim/psp.c:18:nsim_do_psp(struct sk_buff *skb, struct netdevsim *ns,\ndrivers/net/netdevsim/psp.c-19-\t    struct netdevsim *peer_ns, struct skb_ext **psp_ext)\n"
}

95/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 50859
							output: 34
							thoughts: 37

Thoughts:

Okay, here's my take on those thoughts, framed as my own mental process:

**Initial Assessment of Candidate Functions**

Hmm, `nsim_do_psp`... yeah, that one's definitely a strong contender, right off the bat. It just *feels* right for the task at hand. Let's see... gotta be sure before committing, of course.

Okay, time to dive into the codebase. I need to investigate `net/psp/psp_main.c` . It's a key part of this PSP module, so that should provide a good overview of what's going on. I'm especially interested in understanding header writing and modification behavior.

Right, let's look for `psp_write_headers`. This is a classic header operation. Should tell me everything I need to know about where and how this module does its things.

96/2

2026/07/07 03:05

tool

grepper

Args:

{
  "Expression": "psp_write_headers",
  "PathPrefix": "net/psp/psp_main.c"
}

Results:

{
  "Output": "net/psp/psp_main.c=186=EXPORT_SYMBOL(psp_key_size);\nnet/psp/psp_main.c-187-\nnet/psp/psp_main.c:188:static void psp_write_headers(struct net *net, struct sk_buff *skb, __be32 spi,\nnet/psp/psp_main.c-189-\t\t\t      u8 ver, unsigned int udp_len, __be16 sport)\n--\nnet/psp/psp_main.c=248=bool psp_dev_encapsulate(struct net *net, struct sk_buff *skb, __be32 spi,\n--\nnet/psp/psp_main.c-282-\tskb-\u003eencapsulation = 1;\nnet/psp/psp_main.c:283:\tpsp_write_headers(net, skb, spi, ver,\nnet/psp/psp_main.c-284-\t\t\t  skb-\u003elen - skb_transport_offset(skb), sport);\n"
}

97/2

2026/07/07 03:05

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 51382
							output: 40
							thoughts: 42

Thoughts:

Okay, here's my take on those thoughts, framed as my own reasoning:

**Initial Assessment and Exploration**

Hmm, based on this initial prompt, `psp_write_headers` seems like a strong contender as a starting point. That function name feels right, like it could potentially handle the specific kind of header manipulation I'm considering. However, I know better than to jump to conclusions. I've been down that road before and it's always better to cast a wider net at the beginning.

Okay, let's explore a related area and check out what's happening with NAT (Network Address Translation). I think the `net/xfrm` subsystem is a reasonable place to start, given the likely context. Specifically, `xfrm_nat_keepalive.c` - that seems like a good target file since it's about NAT and keep-alives. Let me dig into that...Ah, here we go, `nat_keepalive_send`. That looks promising too. Let me see how things work there...

98/2

2026/07/07 03:06

tool

grepper

Args:

{
  "Expression": "nat_keepalive_send",
  "PathPrefix": "net/xfrm/xfrm_nat_keepalive.c"
}

Results:

{
  "Output": "net/xfrm/xfrm_nat_keepalive.c=31=static void nat_keepalive_init(struct nat_keepalive *ka, struct xfrm_state *x)\n--\nnet/xfrm/xfrm_nat_keepalive.c-41-\nnet/xfrm/xfrm_nat_keepalive.c:42:static int nat_keepalive_send_ipv4(struct sk_buff *skb,\nnet/xfrm/xfrm_nat_keepalive.c-43-\t\t\t\t   struct nat_keepalive *ka)\n--\nnet/xfrm/xfrm_nat_keepalive.c-72-#if IS_ENABLED(CONFIG_IPV6)\nnet/xfrm/xfrm_nat_keepalive.c:73:static int nat_keepalive_send_ipv6(struct sk_buff *skb,\nnet/xfrm/xfrm_nat_keepalive.c-74-\t\t\t\t   struct nat_keepalive *ka,\n--\nnet/xfrm/xfrm_nat_keepalive.c-114-\nnet/xfrm/xfrm_nat_keepalive.c:115:static void nat_keepalive_send(struct nat_keepalive *ka)\nnet/xfrm/xfrm_nat_keepalive.c-116-{\n--\nnet/xfrm/xfrm_nat_keepalive.c-142-\tcase AF_INET:\nnet/xfrm/xfrm_nat_keepalive.c:143:\t\terr = nat_keepalive_send_ipv4(skb, ka);\nnet/xfrm/xfrm_nat_keepalive.c-144-\t\tbreak;\n--\nnet/xfrm/xfrm_nat_keepalive.c-146-\tcase AF_INET6:\nnet/xfrm/xfrm_nat_keepalive.c:147:\t\terr = nat_keepalive_send_ipv6(skb, ka, uh);\nnet/xfrm/xfrm_nat_keepalive.c-148-\t\tbreak;\n--\nnet/xfrm/xfrm_nat_keepalive.c=160=static int nat_keepalive_work_single(struct xfrm_state *x, int count, void *ptr)\n--\nnet/xfrm/xfrm_nat_keepalive.c-189-\tif (send_keepalive)\nnet/xfrm/xfrm_nat_keepalive.c:190:\t\tnat_keepalive_send(\u0026ka);\nnet/xfrm/xfrm_nat_keepalive.c-191-\n"
}

99/2

2026/07/07 03:06

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 52315
							output: 40
							thoughts: 56

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**Investigating Potential TCP Keepalive Optimization**

Right, thinking about this... `nat_keepalive_send` seems like a pretty strong candidate to start with. It's the obvious starting point. I need to understand if the kernel currently does any checksumming in the keepalive path or any related path, so let's dig into that and see if it is necessary.

Now, where was that checksumming logic? Ah, yes, I recall seeing some relevant code in `net/sched/act_csum.c`. I need to review this to see what checksum offload features it may support. Let's see... looking at that file, it looks like `tcf_csum_ipv4_udp` and `tcf_csum_ipv6_udp` might be relevant functions to investigate. I need to understand how these relate to the TCP keepalive process and if there's any intersection or opportunity for optimization there.

100/2

2026/07/07 03:06

tool

grepper

Args:

{
  "Expression": "tcf_csum_ipv4_udp",
  "PathPrefix": "net/sched/act_csum.c"
}

Results:

{
  "Output": "net/sched/act_csum.c=230=static int tcf_csum_ipv6_tcp(struct sk_buff *skb, unsigned int ihl,\n--\nnet/sched/act_csum.c-254-\nnet/sched/act_csum.c:255:static int tcf_csum_ipv4_udp(struct sk_buff *skb, unsigned int ihl,\nnet/sched/act_csum.c-256-\t\t\t     unsigned int ipl, int udplite)\n--\nnet/sched/act_csum.c=389=static int tcf_csum_ipv4(struct sk_buff *skb, u32 update_flags)\n--\nnet/sched/act_csum.c-421-\t\tif (update_flags \u0026 TCA_CSUM_UPDATE_FLAG_UDP)\nnet/sched/act_csum.c:422:\t\t\tif (!tcf_csum_ipv4_udp(skb, iph-\u003eihl * 4,\nnet/sched/act_csum.c-423-\t\t\t\t\t       ntohs(iph-\u003etot_len), 0))\n--\nnet/sched/act_csum.c-427-\t\tif (update_flags \u0026 TCA_CSUM_UPDATE_FLAG_UDPLITE)\nnet/sched/act_csum.c:428:\t\t\tif (!tcf_csum_ipv4_udp(skb, iph-\u003eihl * 4,\nnet/sched/act_csum.c-429-\t\t\t\t\t       ntohs(iph-\u003etot_len), 1))\n"
}

101/2

2026/07/07 03:06

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 53031
							output: 41
							thoughts: 60

Thoughts:

Okay, here's my take on those initial thoughts, framed as a concise summary for an expert:

**Checksum Considerations for UDP in Netfilter**

Right, thinking about checksum handling for UDP packets, my initial gut feeling is that `tcf_csum_ipv4_udp` and `tcf_csum_ipv6_udp` are promising starting points. I'm going to quickly check `net/netfilter/nf_nat_helper.c` to see how NAT might be interacting with these. Specifically, I need to jog my memory about the `nf_nat_mangle_udp_packet` function and how it approaches this. That will probably be the key to understanding any existing checksum modifications.

102/2

2026/07/07 03:06

tool

grepper

Args:

{
  "Expression": "nf_nat_mangle_udp_packet",
  "PathPrefix": "net/netfilter/nf_nat_helper.c"
}

Results:

{
  "Output": "net/netfilter/nf_nat_helper.c=135=bool\nnet/netfilter/nf_nat_helper.c:136:nf_nat_mangle_udp_packet(struct sk_buff *skb,\nnet/netfilter/nf_nat_helper.c-137-\t\t\t struct nf_conn *ct,\n--\nnet/netfilter/nf_nat_helper.c-174-}\nnet/netfilter/nf_nat_helper.c:175:EXPORT_SYMBOL(nf_nat_mangle_udp_packet);\nnet/netfilter/nf_nat_helper.c-176-\n"
}

103/2

2026/07/07 03:06

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 53446
							output: 42
							thoughts: 48

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Analyzing UDP Packet Manipulation Options**

Right, thinking about this... `nf_nat_mangle_udp_packet` seems like a solid starting point for examining how to tweak those UDP packets. It's often the go-to for NAT-related modifications, so it's probably where the action is happening.

Let's dive into the kernel source and check out `net/netfilter/nf_log_syslog.c`. I recall that file having some relevant functions. Specifically, I'll need to check `nf_log_dump_udp_header`. That seems a likely candidate for inspecting and/or adapting the UDP header dumping code for our purposes.

104/2

2026/07/07 03:06

tool

grepper

Args:

{
  "Expression": "nf_log_dump_udp_header",
  "PathPrefix": "net/netfilter/nf_log_syslog.c"
}

Results:

{
  "Output": "net/netfilter/nf_log_syslog.c=276=static noinline_for_stack int\nnet/netfilter/nf_log_syslog.c:277:nf_log_dump_udp_header(struct nf_log_buf *m,\nnet/netfilter/nf_log_syslog.c-278-\t\t       const struct sk_buff *skb,\n--\nnet/netfilter/nf_log_syslog.c=312=dump_ipv4_packet(struct net *net, struct nf_log_buf *m,\n--\nnet/netfilter/nf_log_syslog.c-383-\tcase IPPROTO_UDPLITE:\nnet/netfilter/nf_log_syslog.c:384:\t\tif (nf_log_dump_udp_header(m, skb, ih-\u003eprotocol,\nnet/netfilter/nf_log_syslog.c-385-\t\t\t\t\t   ntohs(ih-\u003efrag_off) \u0026 IP_OFFSET,\n--\nnet/netfilter/nf_log_syslog.c=546=dump_ipv6_packet(struct net *net, struct nf_log_buf *m,\n--\nnet/netfilter/nf_log_syslog.c-711-\tcase IPPROTO_UDPLITE:\nnet/netfilter/nf_log_syslog.c:712:\t\tif (nf_log_dump_udp_header(m, skb, currenthdr, fragment, ptr))\nnet/netfilter/nf_log_syslog.c-713-\t\t\treturn;\n"
}

105/2

2026/07/07 03:06

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 54090
							output: 39
							thoughts: 51

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Initial Assessment: UDP Logging & Error Handling**

Alright, `nf_log_dump_udp_header`... seems like a logging function, which is often more about debugging and post-mortem analysis than critical path performance. Unless something jumps out as profoundly problematic, I'm not going to immediately zero in on that. Let's dig deeper into the UDP connection tracking code itself. I'll need to examine `net/netfilter/nf_conntrack_proto_udp.c` now, specifically the `udp_error` function. That's probably where the meat of the error handling and state management for UDP connections resides. Knowing the error handling strategies will be paramount, and the logging will come in handy later.

106/2

2026/07/07 03:06

tool

grepper

Args:

{
  "Expression": "udp_error",
  "PathPrefix": "net/netfilter/nf_conntrack_proto_udp.c"
}

Results:

{
  "Output": "net/netfilter/nf_conntrack_proto_udp.c=32=static unsigned int *udp_get_timeouts(struct net *net)\n--\nnet/netfilter/nf_conntrack_proto_udp.c-36-\nnet/netfilter/nf_conntrack_proto_udp.c:37:static void udp_error_log(const struct sk_buff *skb,\nnet/netfilter/nf_conntrack_proto_udp.c-38-\t\t\t  const struct nf_hook_state *state,\n--\nnet/netfilter/nf_conntrack_proto_udp.c=44=static bool udp_validate_len(struct sk_buff *skb,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-55-\nnet/netfilter/nf_conntrack_proto_udp.c:56:static bool udp_error(struct sk_buff *skb,\nnet/netfilter/nf_conntrack_proto_udp.c-57-\t\t      unsigned int dataoff,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-65-\tif (!hdr) {\nnet/netfilter/nf_conntrack_proto_udp.c:66:\t\tudp_error_log(skb, state, \"short packet\");\nnet/netfilter/nf_conntrack_proto_udp.c-67-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c-71-\tif (!udp_validate_len(skb, hdr, dataoff)) {\nnet/netfilter/nf_conntrack_proto_udp.c:72:\t\tudp_error_log(skb, state, \"truncated/malformed packet\");\nnet/netfilter/nf_conntrack_proto_udp.c-73-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c-86-\t    nf_checksum(skb, state-\u003ehook, dataoff, IPPROTO_UDP, state-\u003epf)) {\nnet/netfilter/nf_conntrack_proto_udp.c:87:\t\tudp_error_log(skb, state, \"bad checksum\");\nnet/netfilter/nf_conntrack_proto_udp.c-88-\t\treturn true;\n--\nnet/netfilter/nf_conntrack_proto_udp.c=95=int nf_conntrack_udp_packet(struct nf_conn *ct,\n--\nnet/netfilter/nf_conntrack_proto_udp.c-103-\nnet/netfilter/nf_conntrack_proto_udp.c:104:\tif (udp_error(skb, dataoff, state))\nnet/netfilter/nf_conntrack_proto_udp.c-105-\t\treturn -NF_ACCEPT;\n"
}

107/2

2026/07/07 03:06

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 55056
							output: 44
							thoughts: 48

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Initial Assessment and Targeted Investigation**

Alright, sounds like we've got a UDP-related error to troubleshoot. My gut feeling says `udp_error` is a solid starting point for investigation. It seems like it's the natural place to start looking at this kind of problem.

Now, let's dive into some code. My instinct tells me to check the `net/ipv4/netfilter/nf_nat_snmp_basic_main.c` file. This looks like a likely area, as it deals with NAT and potentially SNMP, which could definitely be involved with UDP traffic. I need to refresh my memory on this section of code.

I need to focus on a few key functions: `snmp_translate` and any help functions related to it. Those are the functions I'll need to focus on to get to the bottom of this. That's probably where the root of the error lies.

108/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "snmp_translate",
  "PathPrefix": "net/ipv4/netfilter/nf_nat_snmp_basic_main.c"
}

Results:

{
  "Output": "net/ipv4/netfilter/nf_nat_snmp_basic_main.c=105=int snmp_helper(void *context, size_t hdrlen, unsigned char tag,\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-125-\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c:126:static int snmp_translate(struct nf_conn *ct, int dir, struct sk_buff *skb)\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-127-{\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c=160=static int help(struct sk_buff *skb, unsigned int protoff,\n--\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-194-\tspin_lock_bh(\u0026snmp_lock);\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c:195:\tret = snmp_translate(ct, dir, skb);\nnet/ipv4/netfilter/nf_nat_snmp_basic_main.c-196-\tspin_unlock_bh(\u0026snmp_lock);\n"
}

109/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 55687
							output: 36
							thoughts: 37

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating a Potential SNMP Translation Pathway**

Alright, let's see... the problem is about SNMP translation, so I'm immediately thinking `snmp_translate` – that seems like a strong initial candidate for where this functionality might reside. It's the logical place to start, given the nature of the problem.

Now, where else might this be handled, especially if we're dealing with a constraint network, possibly even 6LoWPAN? Ah, yes, if this SNMP traffic needs to traverse a 6LoWPAN network the UDP part is important to figure out what happens in the transport layer, so let's dig into `net/6lowpan/nhc_udp.c`. That should give us a clearer view of what's happening. I should probably focus on `udp_uncompress`, see how this is translated.

110/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "udp_uncompress",
  "PathPrefix": "net/6lowpan/nhc_udp.c"
}

Results:

{
  "Output": "net/6lowpan/nhc_udp.c-35-\nnet/6lowpan/nhc_udp.c:36:static int udp_uncompress(struct sk_buff *skb, size_t needed)\nnet/6lowpan/nhc_udp.c-37-{\n--\nnet/6lowpan/nhc_udp.c=171=LOWPAN_NHC(nhc_udp, \"RFC6282 UDP\", NEXTHDR_UDP, sizeof(struct udphdr),\nnet/6lowpan/nhc_udp.c:172:\t   LOWPAN_NHC_UDP_ID, LOWPAN_NHC_UDP_MASK, udp_uncompress, udp_compress);\nnet/6lowpan/nhc_udp.c-173-\n"
}

111/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 56161
							output: 36
							thoughts: 37

Thoughts:

Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise:

**Potential Optimization: UDP Uncompression**

Right, thinking about this performance bottleneck, `udp_uncompress` seems like a likely area to investigate. It’s a classic, often-overlooked area for potential gains. I need to understand how efficiently it's handling the incoming data. Where would this logic likely reside? Aha! That's it, I need to check the WireGuard receive path. I'll need to dig into `drivers/net/wireguard/receive.c`. Let's see how they're handling packet reception and the decompressing, it all starts with the `prepare_skb_header` function... Let's see what's happening there.

112/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "prepare_skb_header",
  "PathPrefix": "drivers/net/wireguard/receive.c"
}

Results:

{
  "Output": "drivers/net/wireguard/receive.c=28=static size_t validate_header_len(struct sk_buff *skb)\n--\ndrivers/net/wireguard/receive.c-46-\ndrivers/net/wireguard/receive.c:47:static int prepare_skb_header(struct sk_buff *skb, struct wg_device *wg)\ndrivers/net/wireguard/receive.c-48-{\n--\ndrivers/net/wireguard/receive.c=542=void wg_packet_receive(struct wg_device *wg, struct sk_buff *skb)\ndrivers/net/wireguard/receive.c-543-{\ndrivers/net/wireguard/receive.c:544:\tif (unlikely(prepare_skb_header(skb, wg) \u003c 0))\ndrivers/net/wireguard/receive.c-545-\t\tgoto err;\n"
}

113/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 56633
							output: 39
							thoughts: 42

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**Analyzing Potential Candidates for SKB Header Preparation**

Alright, looking at this problem, `prepare_skb_header` immediately jumps out as a strong contender. That's a logical starting point, considering the name. I'd expect it to be directly involved in the header construction phase.

To be thorough, let's explore related areas. Let me go poke around in `drivers/infiniband/core/lag.c`. That's often a good spot for IB-specific network function interactions, and it might reveal how SKBs are handled in a low-level, high-performance context.

Hmm, okay, after a quick scan of `lag.c`, let's see what `rdma_build_skb` might provide. Perhaps this will be a useful place to start debugging the SKB header construction process.

114/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "rdma_build_skb",
  "PathPrefix": "drivers/infiniband/core/lag.c"
}

Results:

{
  "Output": "drivers/infiniband/core/lag.c-9-\ndrivers/infiniband/core/lag.c:10:static struct sk_buff *rdma_build_skb(struct net_device *netdev,\ndrivers/infiniband/core/lag.c-11-\t\t\t\t      struct rdma_ah_attr *ah_attr,\n--\ndrivers/infiniband/core/lag.c=80=static struct net_device *rdma_get_xmit_slave_udp(struct ib_device *device,\n--\ndrivers/infiniband/core/lag.c-87-\ndrivers/infiniband/core/lag.c:88:\tskb = rdma_build_skb(master, ah_attr, flags);\ndrivers/infiniband/core/lag.c-89-\tif (!skb)\n"
}

115/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 57130
							output: 47
							thoughts: 59

Thoughts:

Here's my thought process, as if I were considering this issue:

**RDMA SKB Construction Investigation**

Okay, so I'm looking for the right approach here. My initial thought is that `rdma_build_skb` might be a really promising starting point, considering the context. Let's see if that's going to work.

Now, where do I start digging? Given my familiarity with RDMA and networking, I'm immediately thinking the `drivers/infiniband/sw/rxe/rxe_net.c` file is the most likely place to find relevant code. Within that, I should focus on functions related to UDP encapsulation and receive paths. That likely means I want to examine `rxe_udp_encap_recv`, which is likely responsible for receiving the packets. I should also check out `prepare_udp_hdr` since that's probably handling the setup of the UDP header which is very relevant to my problem. Let's start there.

116/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "rxe_udp_encap_recv",
  "PathPrefix": "drivers/infiniband/sw/rxe/rxe_net.c"
}

Results:

{
  "Output": "drivers/infiniband/sw/rxe/rxe_net.c=174=static struct dst_entry *rxe_find_route(struct net_device *ndev,\n--\ndrivers/infiniband/sw/rxe/rxe_net.c-218-\ndrivers/infiniband/sw/rxe/rxe_net.c:219:static int rxe_udp_encap_recv(struct sock *sk, struct sk_buff *skb)\ndrivers/infiniband/sw/rxe/rxe_net.c-220-{\n--\ndrivers/infiniband/sw/rxe/rxe_net.c=259=static struct socket *rxe_setup_udp_tunnel(struct net *net, __be16 port,\n--\ndrivers/infiniband/sw/rxe/rxe_net.c-282-\ttnl_cfg.encap_type = 1;\ndrivers/infiniband/sw/rxe/rxe_net.c:283:\ttnl_cfg.encap_rcv = rxe_udp_encap_recv;\ndrivers/infiniband/sw/rxe/rxe_net.c-284-\n"
}

117/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 57765
							output: 48
							thoughts: 61

Thoughts:

Here's my take on those code candidates:

**Thinking Through UDP Encapsulation**

Okay, so I'm thinking about where to start digging into this UDP encapsulation process. Based on my experience, `rxe_udp_encap_recv` and `prepare_udp_hdr` feel like solid starting points. They are likely involved directly in receiving and preparing the UDP headers, which is precisely what I'm interested in here.

However, I'm going to shift gears and delve into `drivers/net/ethernet/sfc/tc_encap_actions.c`. Looking at that file should be interesting because I recall that specific driver dealing with traffic control and encapsulation actions. Specifically, I'm curious about how the `efx_gen_tun_header_udp` function handles UDP. I'd expect that function to be the one responsible for generating or manipulating the UDP headers in this setup, or at least involved in the overall control path. Let's see what secrets it holds.

118/2

2026/07/07 03:07

tool

grepper

Args:

{
  "Expression": "efx_gen_tun_header_udp",
  "PathPrefix": "drivers/net/ethernet/sfc/tc_encap_actions.c"
}

Results:

{
  "Output": "drivers/net/ethernet/sfc/tc_encap_actions.c=286=static void efx_gen_tun_header_ipv6(struct efx_tc_encap_action *encap, u8 ipproto, u8 len)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-304-\ndrivers/net/ethernet/sfc/tc_encap_actions.c:305:static void efx_gen_tun_header_udp(struct efx_tc_encap_action *encap, u8 len)\ndrivers/net/ethernet/sfc/tc_encap_actions.c-306-{\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=350=static void efx_gen_vxlan_header_ipv4(struct efx_tc_encap_action *encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-354-\tefx_gen_tun_header_ipv4(encap, IPPROTO_UDP, vxlan_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:355:\tefx_gen_tun_header_udp(encap, sizeof(struct vxlanhdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-356-\tefx_gen_tun_header_vxlan(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=361=static void efx_gen_geneve_header_ipv4(struct efx_tc_encap_action *encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-365-\tefx_gen_tun_header_ipv4(encap, IPPROTO_UDP, geneve_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:366:\tefx_gen_tun_header_udp(encap, sizeof(struct genevehdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-367-\tefx_gen_tun_header_geneve(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=372=static void efx_gen_vxlan_header_ipv6(struct efx_tc_encap_action *encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-376-\tefx_gen_tun_header_ipv6(encap, IPPROTO_UDP, vxlan_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:377:\tefx_gen_tun_header_udp(encap, sizeof(struct vxlanhdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-378-\tefx_gen_tun_header_vxlan(encap);\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c=382=static void efx_gen_geneve_header_ipv6(struct efx_tc_encap_action *encap)\n--\ndrivers/net/ethernet/sfc/tc_encap_actions.c-386-\tefx_gen_tun_header_ipv6(encap, IPPROTO_UDP, geneve_header_l4_len);\ndrivers/net/ethernet/sfc/tc_encap_actions.c:387:\tefx_gen_tun_header_udp(encap, sizeof(struct genevehdr));\ndrivers/net/ethernet/sfc/tc_encap_actions.c-388-\tefx_gen_tun_header_geneve(encap);\n"
}

119/2

2026/07/07 03:07

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 59058
							output: 50
							thoughts: 57

Thoughts:

Okay, here's my interpretation of those thoughts, tailored for an expert audience, as if they were my own:

**UDP Header Tuning Consideration**

Alright, looking at potential avenues for optimization, `efx_gen_tun_header_udp` definitely stands out as a strong candidate for further investigation. That function feels like a likely point where we can make some meaningful impact.

Now, let's pivot to the Intel i40e driver. I need to take a look at the i40e code, specifically in `drivers/net/ethernet/intel/i40e/i40e_txrx.c`. I suspect there might be some interplay there. I'm also remembering `i40e_tso`, that could potentially be involved here as well. I'll need to drill down and see how that is managed in relation to UDP header generation.

120/2

2026/07/07 03:08

tool

grepper

Args:

{
  "Expression": "i40e_tso",
  "PathPrefix": "drivers/net/ethernet/intel/i40e/i40e_txrx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/intel/i40e/i40e_txrx.c=3001=static inline int i40e_tx_prepare_vlan_flags(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3067-/**\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3068: * i40e_tso - set up the tso context descriptor\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3069- * @first:    pointer to first Tx buffer for xmit\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3074- **/\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3075:static int i40e_tso(struct i40e_tx_buffer *first, u8 *hdr_len,\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3076-\t\t    u64 *cd_type_cmd_tso_mss)\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c=3868=static netdev_tx_t i40e_xmit_frame_ring(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3916-\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c:3917:\ttso = i40e_tso(first, \u0026hdr_len, \u0026cd_type_cmd_tso_mss);\ndrivers/net/ethernet/intel/i40e/i40e_txrx.c-3918-\n"
}

121/2

2026/07/07 03:08

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 59864
							output: 44
							thoughts: 48

Thoughts:

Okay, here's my interpretation of those thoughts, tailored for an expert audience:

**Considering TSO Implementation in Intel Network Drivers**

Alright, so I'm thinking about where to start looking at TSO implementation, and `i40e_tso` immediately jumps out as a strong possibility. It's a key driver, after all. Now, I want to drill down and see how it is actually handled. I'm going to quickly check `drivers/net/ethernet/intel/iavf/iavf_txrx.c` to see how the IAVF driver handles TSO, the related function `iavf_tso` is the exact function to examine, as I expect it to contain details on TSO-related processing.

122/2

2026/07/07 03:09

tool

grepper

Args:

{
  "Expression": "iavf_tso",
  "PathPrefix": "drivers/net/ethernet/intel/iavf/iavf_txrx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/intel/iavf/iavf_txrx.c=1696=static void iavf_tx_prepare_vlan_flags(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1721-/**\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:1722: * iavf_tso - set up the tso context descriptor\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1723- * @first:    pointer to first Tx buffer for xmit\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1728- **/\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:1729:static int iavf_tso(struct iavf_tx_buffer *first, u8 *hdr_len,\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-1730-\t\t    u64 *cd_type_cmd_tso_mss)\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c=2291=static netdev_tx_t iavf_xmit_frame_ring(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-2352-\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c:2353:\ttso = iavf_tso(first, \u0026hdr_len, \u0026cd_type_cmd_tso_mss);\ndrivers/net/ethernet/intel/iavf/iavf_txrx.c-2354-\n"
}

123/2

2026/07/07 03:09

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 60570
							output: 41
							thoughts: 43

Thoughts:

Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested:

**Assessing TSO Implementation**

Alright, looking at this networking code, `iavf_tso` is a likely contender for what I'm looking for. That seems to fit the bill based on what I know about this driver. Now, the next logical step is to dive into the implementation. I'll need to check the code that actually handles the Transmit Side Offload (TSO) functionality. Specifically, I'll navigate to `drivers/net/ethernet/intel/ice/ice_txrx.c` because that's where Intel drivers typically keep their core transmit and receive logic. Within that file, I'm betting that functions related to `ice_tso` will be the key. Let's start there. I'll get into the details of the actual function calls and data structures involved, but that's my initial hypothesis.

124/2

2026/07/07 03:09

tool

grepper

Args:

{
  "Expression": "ice_tso",
  "PathPrefix": "drivers/net/ethernet/intel/ice/ice_txrx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/intel/ice/ice_txrx.c=1812=ice_tx_prepare_vlan_flags(struct ice_tx_ring *tx_ring, struct ice_tx_buf *first)\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1835-/**\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1836: * ice_tso - computes mss and TSO length to prepare for TSO\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1837- * @first: pointer to struct ice_tx_buf\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c=1842=static\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1843:int ice_tso(struct ice_tx_buf *first, struct ice_tx_offload_params *off)\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1844-{\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c=2159=ice_xmit_frame_ring(struct sk_buff *skb, struct ice_tx_ring *tx_ring)\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-2213-\t/* set up TSO offload */\ndrivers/net/ethernet/intel/ice/ice_txrx.c:2214:\ttso = ice_tso(first, \u0026offload);\ndrivers/net/ethernet/intel/ice/ice_txrx.c-2215-\tif (tso \u003c 0)\n"
}

125/2

2026/07/07 03:09

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 61294
							output: 44
							thoughts: 45

Thoughts:

Okay, here's my take on those thoughts, framed as my own mental process, given that I'm an expert:

**TSO Candidate Evaluation and Code Dive**

Right, let's see... `ice_tso`... yeah, that seems like a solid potential candidate for the TSO (TCP Segmentation Offload) implementation within the Intel network driver context. It's a plausible identifier for a TSO-specific function or module.

Now, where to confirm? Given the context of Intel Ethernet drivers, the logical place to start digging is within the `drivers/net/ethernet/intel/idpf/` directory. And within that, let's target `idpf_txrx.c` which, with the `txrx` designation, seems likely to contain the transmit and receive path code. That file is probably where the TSO handling would be.

Specifically, I'll be looking for `idpf_tso`. It's highly probable the function names will follow a consistent naming scheme. So, the likelihood of finding `idpf_tso` inside that file to confirm that hypothesis is high. Let's see if that's where we find the relevant TSO implementation details.

126/2

2026/07/07 03:11

tool

grepper

Args:

{
  "Expression": "idpf_tso",
  "PathPrefix": "drivers/net/ethernet/intel/idpf/idpf_txrx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/intel/idpf/idpf_txrx.c=2642=static void idpf_tx_splitq_map(struct idpf_tx_queue *tx_q,\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2813-/**\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:2814: * idpf_tso - computes mss and TSO length to prepare for TSO\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2815- * @skb: pointer to skb\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2820- */\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:2821:int idpf_tso(struct sk_buff *skb, struct idpf_tx_offload_params *off)\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-2822-{\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c=3021=static netdev_tx_t idpf_tx_splitq_frame(struct sk_buff *skb,\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-3036-\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c:3037:\ttso = idpf_tso(skb, \u0026tx_params.offload);\ndrivers/net/ethernet/intel/idpf/idpf_txrx.c-3038-\tif (unlikely(tso \u003c 0))\n"
}

127/2

2026/07/07 03:11

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 62086
							output: 56
							thoughts: 58

Thoughts:

Okay, here's my interpretation of those thoughts, framed as my own:

**Initial Assessment of Candidate and Code Location**

Right, `idpf_tso`... that definitely seems like a strong contender for what I'm looking for. Let's make sure, I need to understand it better. My next step will be to dive into `drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c`. This is where I'd expect to find the lower-level details, especially anything related to transmission and reception, given the filename. And in particular I want to review `otx2_sqe_add_ext`. I'm hoping it'll shed light on the intricacies of how this TSO (or related) functionality is implemented.

128/2

2026/07/07 03:11

tool

grepper

Args:

{
  "Expression": "otx2_sqe_add_ext",
  "PathPrefix": "drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c=662=static bool otx2_sqe_add_sg(struct otx2_nic *pfvf, struct otx2_snd_queue *sq,\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-706-/* Add SQE extended header subdescriptor */\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:707:static void otx2_sqe_add_ext(struct otx2_nic *pfvf, struct otx2_snd_queue *sq,\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-708-\t\t\t     struct sk_buff *skb, int *offset)\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c=1189=bool otx2_sq_append_skb(void *dev, struct netdev_queue *txq,\n--\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-1244-\t/* Add extended header if needed */\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c:1245:\totx2_sqe_add_ext(pfvf, sq, skb, \u0026offset);\ndrivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c-1246-\n"
}

129/2

2026/07/07 03:11

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 62798
							output: 56
							thoughts: 81

Thoughts:

Here's my analysis of those findings:

**Considering Packet Modification Points**

Okay, so I'm looking for the ideal spot to inject a modification. `otx2_sqe_add_ext` feels like a strong contender – it seems like the right level of abstraction to potentially intercept and manipulate packets before they're fully processed. I'll need to confirm that it's the right place, but my gut feeling is positive.

Now, let's dive into the code. I'll navigate over to `drivers/net/ethernet/mellanox/mlx5/core/en_rx.c` specifically, the Mellanox Ethernet driver. Given the context, that's where I expect to find relevant RX path processing.

Aha! It looks like `mlx5e_shampo_update_ipv4_udp_hdr` and `mlx5e_shampo_update_ipv6_udp_hdr` are prime targets! These functions specifically suggest they are involved in updating the headers of UDP packets, which is exactly where I'm aiming. They handle the IPv4 and IPv6 variants separately, meaning I need to make sure my logic covers both cases. My next step will be to thoroughly examine these functions to understand how and when the header updates happen, and identify the point at which to inject my changes.

130/2

2026/07/07 03:11

tool

grepper

Args:

{
  "Expression": "mlx5e_shampo_update_ipv4_udp_hdr",
  "PathPrefix": "drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"
}

Results:

{
  "Output": "drivers/net/ethernet/mellanox/mlx5/core/en_rx.c=1021=static unsigned int mlx5e_lro_update_hdr(struct sk_buff *skb,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1076-\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c:1077:static void mlx5e_shampo_update_ipv4_udp_hdr(struct mlx5e_rq *rq, struct iphdr *ipv4)\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1078-{\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c=1207=static void mlx5e_shampo_update_hdr(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe, bool match)\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1225-\t\telse\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c:1226:\t\t\tmlx5e_shampo_update_ipv4_udp_hdr(rq, ipv4);\ndrivers/net/ethernet/mellanox/mlx5/core/en_rx.c-1227-\t} else {\n"
}

131/2

2026/07/07 03:11

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 63587
							output: 42
							thoughts: 71

Thoughts:

Here's my analysis of the situation:

**Potential Optimization Candidates**

Okay, so I'm thinking about where we might be able to make some headway here. Based on what I've seen, `mlx5e_shampo_update_ipv4_udp_hdr` and `mlx5e_shampo_update_ipv6_udp_hdr` seem like particularly promising areas to focus on. They deal with the header updates, which are often performance-sensitive spots.

Now, I'm going to take a look into the `drivers/net/ethernet/sfc/falcon/selftest.c` file. I'm specifically interested in the `ef4_iterate_state` function within that file. I'll need to see if there's any relevant logic or potential insights that will provide some helpful insight into optimizing the headers.

132/2

2026/07/07 03:11

tool

grepper

Args:

{
  "Expression": "ef4_iterate_state",
  "PathPrefix": "drivers/net/ethernet/sfc/falcon/selftest.c"
}

Results:

{
  "Output": "drivers/net/ethernet/sfc/falcon/selftest.c=288=void ef4_loopback_rx_packet(struct ef4_nic *efx,\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c-381-/* Initialise an ef4_selftest_state for a new iteration */\ndrivers/net/ethernet/sfc/falcon/selftest.c:382:static void ef4_iterate_state(struct ef4_nic *efx)\ndrivers/net/ethernet/sfc/falcon/selftest.c-383-{\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c=537=ef4_test_loopback(struct ef4_tx_queue *tx_queue,\n--\ndrivers/net/ethernet/sfc/falcon/selftest.c-557-\ndrivers/net/ethernet/sfc/falcon/selftest.c:558:\t\tef4_iterate_state(efx);\ndrivers/net/ethernet/sfc/falcon/selftest.c-559-\t\tbegin_rc = ef4_begin_loopback(tx_queue);\n"
}

133/2

2026/07/07 03:11

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 64179
							output: 55
							thoughts: 64

Thoughts:

Okay, let's get down to business. Here's how I'm approaching this:

**Initial Assessment and Targeted Investigation**

Alright, looking over this, I see `ef4_iterate_state` listed as a selftest function. I know that function, and in my experience, it's not the primary focus right now. It's safe to skip it for the purposes of a quick triage and not worth the time to investigate further, given the context.

My attention is immediately drawn to the `drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c` file. The networking stack and STMicroelectronics' (ST) MAC driver are important in many systems I've worked on. I want to zero in on specific test cases, and the mention of `stmmac_test_get_udp_skb` is intriguing. That looks like a good place to start, as UDP testing can often reveal subtleties in driver and network stack interactions. I'll focus my efforts there to quickly understand potential testing methodologies and code behavior.

134/2

2026/07/07 03:12

tool

grepper

Args:

{
  "Expression": "stmmac_test_get_udp_skb",
  "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c"
}

Results:

{
  "Output": "drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=57=static u8 stmmac_test_next_id;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-58-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:59:static struct sk_buff *stmmac_test_get_udp_skb(struct stmmac_priv *priv,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-60-\t\t\t\t\t       struct stmmac_packet_attrs *attr)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=320=static int __stmmac_test_loopback(struct stmmac_priv *priv,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-342-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:343:\tskb = stmmac_test_get_udp_skb(priv, attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-344-\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=894=static int __stmmac_test_vlanfilt(struct stmmac_priv *priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-932-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:933:\t\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-934-\t\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=987=static int __stmmac_test_dvlanfilt(struct stmmac_priv *priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1026-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1027:\t\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1028-\t\tif (!skb) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c=1258=static int stmmac_test_vlanoff_common(struct stmmac_priv *priv, bool svlan)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1292-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c:1293:\tskb = stmmac_test_get_udp_skb(priv, \u0026attr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c-1294-\tif (!skb) {\n"
}

135/2

2026/07/07 03:12

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 65399
							output: 37
							thoughts: 52

Thoughts:

Here's my thought process, as requested:

**Assessing the Self-Test Landscape**

Alright, let's get down to business. I see `stmmac_test_get_udp_skb` listed in the tests. Hmm, that looks like a very specific, low-level function related to the stmmac driver. I'm going to skip that one for now; it's probably not where I want to focus my attention for a broader understanding.

Instead, I'll shift gears. I'll need to look at more general networking functionality. My instincts tell me the place to start is likely in `net/core/selftests.c`. It's a standard location for core network self-tests. That makes sense. I need to get a high-level view of core net-tests.

Okay, now let's see what's in there... Ah, there it is: `net_test_get_skb`. Let's focus on that one next.

136/2

2026/07/07 03:12

tool

grepper

Args:

{
  "Expression": "net_test_get_skb",
  "PathPrefix": "net/core/selftests.c"
}

Results:

{
  "Output": "net/core/selftests.c=17=static u8 net_test_next_id;\nnet/core/selftests.c-18-\nnet/core/selftests.c:19:struct sk_buff *net_test_get_skb(struct net_device *ndev, u8 id,\nnet/core/selftests.c-20-\t\t\t\t struct net_packet_attrs *attr)\n--\nnet/core/selftests.c-156-}\nnet/core/selftests.c:157:EXPORT_SYMBOL_GPL(net_test_get_skb);\nnet/core/selftests.c-158-\n--\nnet/core/selftests.c=233=static int __net_test_loopback(struct net_device *ndev,\n--\nnet/core/selftests.c-253-\nnet/core/selftests.c:254:\tskb = net_test_get_skb(ndev, net_test_next_id, attr);\nnet/core/selftests.c-255-\tif (!skb) {\n"
}

137/2

2026/07/07 03:12

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 65997
							output: 38
							thoughts: 49

Thoughts:

Okay, here's my summary, taking the perspective of someone familiar with kernel development and testing:

**Blackhole Device KUnit Test Exploration**

Right, so I'm scanning through the test suite and, frankly, `net_test_get_skb` doesn't really ring any bells, and it's probably a basic self-test, so I'm going to skip over that. Not really worth digging into. Let's move on to something more interesting.

Okay, now *this* is more like it... `lib/tests/blackhole_dev_kunit.c`. That name sounds promising! I want to understand how the blackhole device is being tested. Time to check out the `test_blackholedev` function within that file. That's the specific test I'm going to focus on.

138/2

2026/07/07 03:12

tool

grepper

Args:

{
  "Expression": "test_blackholedev",
  "PathPrefix": "lib/tests/blackhole_dev_kunit.c"
}

Results:

{
  "Output": "lib/tests/blackhole_dev_kunit.c-26-\nlib/tests/blackhole_dev_kunit.c:27:static void test_blackholedev(struct kunit *test)\nlib/tests/blackhole_dev_kunit.c-28-{\n--\nlib/tests/blackhole_dev_kunit.c=71=static struct kunit_case blackholedev_cases[] = {\nlib/tests/blackhole_dev_kunit.c:72:\tKUNIT_CASE(test_blackholedev),\nlib/tests/blackhole_dev_kunit.c-73-\t{},\n"
}

139/2

2026/07/07 03:12

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 66426
							output: 34
							thoughts: 82

Thoughts:

Here's my thought process, as if I were reviewing this code:

**Quick Scan of Relevant Code**

Alright, I'm going through this code, and the first thing I see is a KUnit test, `test_blackholedev`. Not something I need to delve into for this particular review, so I'll skip over that one.

Next, I'll take a look at `include/trace/events/icmp.h`. Aha, `TRACE_EVENT(icmp_send, ...)` indicates a tracepoint definition. I'm generally not interested in the tracepoints at this stage, so I'll bypass this as well.

Now, let's move on to `net/ipv4/udp.c`. I'm curious about the UDP implementation, so I'll see what's in here. Okay, I see `udp_send_skb`. This looks like a function of interest. I will take note of that.

140/2

2026/07/07 03:12

tool

grepper

Args:

{
  "Expression": "udp_send_skb",
  "PathPrefix": "net/ipv4/udp.c"
}

Results:

{
  "Output": "net/ipv4/udp.c=1091=EXPORT_SYMBOL(udp_set_csum);\nnet/ipv4/udp.c-1092-\nnet/ipv4/udp.c:1093:static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,\nnet/ipv4/udp.c-1094-\t\t\tstruct inet_cork *cork)\n--\nnet/ipv4/udp.c=1179=int udp_push_pending_frames(struct sock *sk)\n--\nnet/ipv4/udp.c-1190-\nnet/ipv4/udp.c:1191:\terr = udp_send_skb(skb, fl4, \u0026inet-\u003ecork.base);\nnet/ipv4/udp.c-1192-\n--\nnet/ipv4/udp.c=1235=int udp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)\n--\nnet/ipv4/udp.c-1444-\t\tif (!IS_ERR_OR_NULL(skb))\nnet/ipv4/udp.c:1445:\t\t\terr = udp_send_skb(skb, fl4, \u0026cork);\nnet/ipv4/udp.c-1446-\t\tgoto out;\n"
}

141/2

2026/07/07 03:12

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 67091
							output: 37
							thoughts: 50

Thoughts:

Okay, here's my take on those thoughts, framed as my own mental processing:

**Analyzing the UDP Send Path**

Alright, so `udp_send_skb` is a critical path, a known hotspot, and I've seen it's been touched recently. That definitely means it needs to be included in my analysis. It's too important to skip over.

Now, where do I start looking? Let's check `net/ipv6/udp.c`. It's likely that the IPv6 version, `udp_v6_send_skb`, will be the key function to examine there. I'll focus my investigation on that function and its interactions.

142/2

2026/07/07 03:12

tool

grepper

Args:

{
  "Expression": "udp_v6_send_skb",
  "PathPrefix": "net/ipv6/udp.c"
}

Results:

{
  "Output": "net/ipv6/udp.c=1313=static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,\n--\nnet/ipv6/udp.c-1353-\nnet/ipv6/udp.c:1354:static int udp_v6_send_skb(struct sk_buff *skb, struct flowi6 *fl6,\nnet/ipv6/udp.c-1355-\t\t\t   struct inet_cork *cork)\n--\nnet/ipv6/udp.c=1436=static int udp_v6_push_pending_frames(struct sock *sk)\n--\nnet/ipv6/udp.c-1448-\nnet/ipv6/udp.c:1449:\terr = udp_v6_send_skb(skb, \u0026inet_sk(sk)-\u003ecork.fl.u.ip6,\nnet/ipv6/udp.c-1450-\t\t\t      \u0026inet_sk(sk)-\u003ecork.base);\n--\nnet/ipv6/udp.c=1457=int udpv6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)\n--\nnet/ipv6/udp.c-1710-\t\tif (!IS_ERR_OR_NULL(skb))\nnet/ipv6/udp.c:1711:\t\t\terr = udp_v6_send_skb(skb, fl6, \u0026cork.base);\nnet/ipv6/udp.c-1712-\t\t/* ip6_make_skb steals dst reference */\n"
}

143/2

2026/07/07 03:12

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 67732
							output: 32
							thoughts: 48

Thoughts:

Here's my analysis of the provided snippet, rendered as a first-person expert summary:

**Analyzing UDP Performance Hotspots**

Okay, so I'm diving into this UDP code, and the first thing that jumps out is that `udp_v6_send_skb` is a known performance bottleneck, a hot path. And even more interesting, it's been *modified*. That definitely needs to be included in my analysis; I need to understand those changes and their impact.

Now, I'm heading over to the more general UDP code for IPv4, specifically `net/ipv4/udp.c`, just to get a broader understanding of the overall flow and any potential interactions or dependencies. I want to quickly refresh myself on the receive side, so `udp_rcv` is the function I will be investigating, the core receive function. I will be looking for interactions. I will also be looking for any clues about interactions with the IPv6 path.

144/2

2026/07/07 03:13

tool

grepper

Args:

{
  "Expression": "udp_rcv",
  "PathPrefix": "net/ipv4/udp.c"
}

Results:

{
  "Output": "net/ipv4/udp.c=1511=void udp_splice_eof(struct socket *sock)\n--\nnet/ipv4/udp.c-1527-/* all head states (dst, sk, nf conntrack) except skb extensions are\nnet/ipv4/udp.c:1528: * cleared by udp_rcv().\nnet/ipv4/udp.c-1529- *\n--\nnet/ipv4/udp.c=2424=static int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/udp.c-2433-\t__skb_push(skb, -skb_mac_offset(skb));\nnet/ipv4/udp.c:2434:\tsegs = udp_rcv_segment(sk, skb, true);\nnet/ipv4/udp.c-2435-\tskb_list_walk_safe(segs, skb, next) {\n--\nnet/ipv4/udp.c=2568=static int udp_unicast_rcv_skb(struct sock *sk, struct sk_buff *skb,\n--\nnet/ipv4/udp.c-2589-\nnet/ipv4/udp.c:2590:int udp_rcv(struct sk_buff *skb)\nnet/ipv4/udp.c-2591-{\n"
}

145/2

2026/07/07 03:13

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 68380
							output: 34
							thoughts: 40

146/2

2026/07/07 03:13

tool

grepper

Args:

{
  "Expression": "udpv6_rcv",
  "PathPrefix": "net/ipv6/udp.c"
}

Results:

{
  "Output": "net/ipv6/udp.c=1035=static int udp6_csum_init(struct sk_buff *skb, struct udphdr *uh)\n--\nnet/ipv6/udp.c-1066-\nnet/ipv6/udp.c:1067:INDIRECT_CALLABLE_SCOPE int udpv6_rcv(struct sk_buff *skb)\nnet/ipv6/udp.c-1068-{\n--\nnet/ipv6/udp.c=1937=int __init udpv6_init(void)\n--\nnet/ipv6/udp.c-1941-\tnet_hotdata.udpv6_protocol = (struct inet6_protocol) {\nnet/ipv6/udp.c:1942:\t\t.handler     = udpv6_rcv,\nnet/ipv6/udp.c-1943-\t\t.err_handler = udpv6_err,\n"
}

147/2

2026/07/07 03:13

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 68694
							output: 27
							thoughts: 1358

Thoughts:

**My UDP Optimization Strategy**

Okay, so `udpv6_rcv` is definitely a performance bottleneck; I'll be steering clear of that. The plan is to see what kind of configuration changes I can get away with, to improve performance.

Let's start by looking at a list of functions that seem to touch UDP in various ways, to see if there are any that I can remove from the configuration:
`__udp_gso_segment`, `udp_gro_complete`, `udp4_gro_complete`, `udp6_gro_complete`, `udp_tunnel_xmit_skb`, `udp_tunnel6_xmit_skb`, `__skb_udp_tunnel_segment`, `udp_gro_receive_segment`, `fou_build_udp`, `fou6_build_udp`, `esp_output_udp_encap`, `esp6_output_udp_encap`, `l2tp_xmit_core`, `ipvs_gue_encap`, `tso_build_hdr`, `skb_segment`, `amt_send_discovery`, `nsim_do_psp`, `psp_write_headers`, `nat_keepalive_send`, `tcf_csum_ipv4_udp`, `tcf_csum_ipv6_udp`, `nf_nat_mangle_udp_packet`, `udp_error`, `snmp_translate`, `udp_uncompress`, `prepare_skb_header`, `rdma_build_skb`, `rxe_udp_encap_recv`, `efx_gen_tun_header_udp`, `i40e_tso`, `iavf_tso`, `ice_tso`, `idpf_tso`, `otx2_sqe_add_ext`, `mlx5e_shampo_update_ipv4_udp_hdr`, `mlx5e_shampo_update_ipv6_udp_hdr`, `inet_rtm_getroute_build_skb`, `fill_packet_ipv4`, `fill_packet_ipv6`. That’s a good starting point. I could just disable these features and then start to profile it.

Now, let's move on to the relevant kernel configuration options.

I'll check these configs: `VXLAN`, `GENEVE`, `NET_FOU`, `INET_ESP`, `INET6_ESP`, `L2TP`, `IP_VS`, `AMT`, `WIREGUARD`, `6LOWPAN_NHC_UDP`, `NF_NAT_SNMP_BASIC`, `NET_ACT_CSUM`, `RDMA_RXE`, `NETDEVSIM`, and `INET_PSP`.

A quick review: `INET_PSP` is PSP Security Protocol support, `NETDEVSIM` is the simulated networking device, `RDMA_RXE` is Software RDMA over Ethernet (RoCE) driver, `NET_ACT_CSUM` is Checksum Updating, `NF_NAT_SNMP_BASIC` is Basic SNMP-ALG support, `6LOWPAN_NHC_UDP` is UDP Header Support, `WIREGUARD` is WireGuard secure network tunnel, `AMT` is Automatic Multicast Tunneling (AMT), `IP_VS` is IP virtual server support, `L2TP` is Layer Two Tunneling Protocol (L2TP), `INET_ESP` is IP: ESP transformation, `INET6_ESP` is IPv6: ESP transformation, `NET_FOU` is IP: Foo (IP protocols) over UDP, `GENEVE` is Generic Network Virtualization Encapsulation, and `VXLAN` is Virtual eXtensible Local Area Network (VXLAN).

I'll also include `NET_UDP_TUNNEL` just in case, but it's often enabled by `VXLAN` and `GENEVE`. Now I should be able to start testing the configuration and see how the performance numbers change.

148/2

2026/07/07 03:13

tool

grepper

Args:

{
  "Expression": "config NET_UDP_TUNNEL",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/Kconfig=304=config NET_IPVTI\n--\nnet/ipv4/Kconfig-315-\nnet/ipv4/Kconfig:316:config NET_UDP_TUNNEL\nnet/ipv4/Kconfig-317-\ttristate\n"
}

149/2

2026/07/07 03:13

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 71027
							output: 25
							thoughts: 41

Thoughts:

Okay, here's my take on those thoughts, tailored for an expert audience, as if they were my own:

**Tristate Selection and Configuration Review**

Alright, this is a tristate, and crucially, it's *not* being driven by a direct prompt. That immediately flags it as being selected by other configuration options, so there's no need to explicitly document it or think of it that way. My focus is going to be elsewhere. I need to understand *why* it's being selected, its dependencies, and its impact on the final configuration.

Let me just quickly verify `CONFIG_INET_PSP`. I want to make sure the relevant config is what I expect. I need to be sure the system is behaving as I anticipate.

150/2

2026/07/07 03:13

tool

grepper

Args:

{
  "Expression": "config INET_PSP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/psp/Kconfig-4-#\nnet/psp/Kconfig:5:config INET_PSP\nnet/psp/Kconfig-6-\tbool \"PSP Security Protocol support\"\n"
}

151/2

2026/07/07 03:13

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 71308
							output: 25
							thoughts: 24

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Quick Verification & Next Steps**

Alright, yep, confirmed. `INET_PSP` is definitely the right variable to be focusing on here. No need to second-guess that initial assessment. Now, given that confirmation, I think we should probably double-check that `CONFIG_NETDEVSIM` flag. That variable often plays a pivotal role in the kinds of interactions we're talking about, and it's always smart to have that one firmly in mind for the path forward. It's a key piece of the puzzle.

152/2

2026/07/07 03:14

tool

grepper

Args:

{
  "Expression": "config NETDEVSIM",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=602=source \"drivers/net/hyperv/Kconfig\"\ndrivers/net/Kconfig-603-\ndrivers/net/Kconfig:604:config NETDEVSIM\ndrivers/net/Kconfig-605-\ttristate \"Simulated networking device\"\n"
}

153/2

2026/07/07 03:14

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 71577
							output: 26
							thoughts: 26

Thoughts:

Okay, here's my summary, presented as a stream of thought:

**Checking the RDMA Configuration**

Right, `NETDEVSIM` looks good, that aligns with my expectations. Always good to have that confirmation. Now, let's just quickly double-check that `CONFIG_RDMA_RXE` is enabled. It's crucial for the RDMA path, and I need to be absolutely certain it's correctly configured given the current circumstances. Making sure this configuration parameter is correct will ensure that there are no issues in running RDMA over the virtual network.

154/2

2026/07/07 03:14

tool

grepper

Args:

{
  "Expression": "config RDMA_RXE",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/infiniband/sw/rxe/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/infiniband/sw/rxe/Kconfig:2:config RDMA_RXE\ndrivers/infiniband/sw/rxe/Kconfig-3-\ttristate \"Software RDMA over Ethernet (RoCE) driver\"\n"
}

155/2

2026/07/07 03:14

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 71852
							output: 27
							thoughts: 28

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Checking RDMA Configuration**

Right, `RDMA_RXE` *is* definitely the correct flag. No need to second-guess that. Now, just to be absolutely certain and to cover all our bases, let's just quickly confirm that `CONFIG_NET_ACT_CSUM` is enabled as well. It's a quick sanity check that often catches those subtle, but crucial, dependencies. Can't be too careful when dealing with network performance.

156/2

2026/07/07 03:14

tool

grepper

Args:

{
  "Expression": "config NET_ACT_CSUM",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/sched/Kconfig=797=config NET_ACT_SKBEDIT\n--\nnet/sched/Kconfig-807-\nnet/sched/Kconfig:808:config NET_ACT_CSUM\nnet/sched/Kconfig-809-\ttristate \"Checksum Updating\"\n"
}

157/2

2026/07/07 03:14

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 72112
							output: 29
							thoughts: 31

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**Quick Verification & Next Steps**

Yep, `NET_ACT_CSUM` is definitely the right parameter for that. Seems straightforward enough. Now, before I move on, I should quickly verify the status of `CONFIG_NF_NAT_SNMP_BASIC`. I vaguely recall something about that potentially impacting the setup, so a quick confirmation will save me any backtracking later. Just a quick double-check to ensure smooth sailing.

158/2

2026/07/07 03:14

tool

grepper

Args:

{
  "Expression": "config NF_NAT_SNMP_BASIC",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/netfilter/Kconfig=99=if NF_NAT\nnet/ipv4/netfilter/Kconfig:100:config NF_NAT_SNMP_BASIC\nnet/ipv4/netfilter/Kconfig-101-\ttristate \"Basic SNMP-ALG support\"\n"
}

159/2

2026/07/07 03:14

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 72362
							output: 30
							thoughts: 33

Thoughts:

Okay, here's my take on those thoughts, framed as my own reasoning:

**Checking the Configuration Parameters**

Alright, yep, I'm confirming that `NF_NAT_SNMP_BASIC` is definitely the right choice in this scenario. Makes perfect sense given the context. Now, just to be absolutely thorough, I want to quickly verify `CONFIG_6LOWPAN_NHC_UDP` while I'm at it. Gotta make sure everything's ship-shape and secure.

160/2

2026/07/07 03:15

tool

grepper

Args:

{
  "Expression": "config 6LOWPAN_NHC_UDP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/6lowpan/Kconfig=59=config 6LOWPAN_NHC_ROUTING\n--\nnet/6lowpan/Kconfig-64-\nnet/6lowpan/Kconfig:65:config 6LOWPAN_NHC_UDP\nnet/6lowpan/Kconfig-66-\ttristate \"UDP Header Support\"\n"
}

161/2

2026/07/07 03:15

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 72627
							output: 25
							thoughts: 29

Thoughts:

Okay, here's my take on those thoughts, framed as my own mental processing:

**Quick Verification & Next Steps**

Yep, I'm confident that `6LOWPAN_NHC_UDP` is the right configuration option here. That's settled. Now, before I move on to the next task, I should just quickly double-check the status of `CONFIG_WIREGUARD`. It's always a good practice to confirm the status of related configurations, especially when moving between distinct feature sets. I want to make sure I'm not missing anything that could impact the overall system configuration. Just a quick sanity check to avoid any future surprises.

162/2

2026/07/07 03:15

tool

grepper

Args:

{
  "Expression": "config WIREGUARD",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=59=config DUMMY\n--\ndrivers/net/Kconfig-73-\ndrivers/net/Kconfig:74:config WIREGUARD\ndrivers/net/Kconfig-75-\ttristate \"WireGuard secure network tunnel\"\n--\ndrivers/net/Kconfig-91-\ndrivers/net/Kconfig:92:config WIREGUARD_DEBUG\ndrivers/net/Kconfig-93-\tbool \"Debugging checks and verbose messages\"\n"
}

163/2

2026/07/07 03:15

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 72949
							output: 22
							thoughts: 22

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Confirmation and a Quick Check**

Yes, that's right, `WIREGUARD` is definitely the key here. That's the correct initial assessment. Now, just to be absolutely certain, let's take a quick look at `CONFIG_AMT` again. We'll rule it out, and then we're free to focus on the area of `WIREGUARD` that needs the most attention.

164/2

2026/07/07 03:15

tool

grepper

Args:

{
  "Expression": "config AMT",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=289=config PFCP\n--\ndrivers/net/Kconfig-301-\ndrivers/net/Kconfig:302:config AMT\ndrivers/net/Kconfig-303-\ttristate \"Automatic Multicast Tunneling (AMT)\"\n"
}

165/2

2026/07/07 03:15

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 73184
							output: 24
							thoughts: 21

Thoughts:

Okay, here's my take on those thoughts, tailored for an expert audience:

**Confirming & Refining Assumptions**

Alright, that initial assessment regarding `AMT` seems spot-on. No need to second-guess that. Now, let's just quickly verify the state of `CONFIG_IP_VS`. While it's likely where I expect it to be, a quick double-check always helps avoid a potential gotcha down the line. It's about being thorough, even with things that feel self-evident. A simple verification here saves time in the long run.

166/2

2026/07/07 03:15

tool

grepper

Args:

{
  "Expression": "config IP_VS",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/netfilter/ipvs/Kconfig-4-#\nnet/netfilter/ipvs/Kconfig:5:menuconfig IP_VS\nnet/netfilter/ipvs/Kconfig-6-\ttristate \"IP virtual server support\"\n--\nnet/netfilter/ipvs/Kconfig=286=comment 'IPVS SH scheduler'\nnet/netfilter/ipvs/Kconfig-287-\nnet/netfilter/ipvs/Kconfig:288:config IP_VS_SH_TAB_BITS\nnet/netfilter/ipvs/Kconfig-289-\tint \"IPVS source hashing table size (the Nth power of 2)\"\n--\nnet/netfilter/ipvs/Kconfig=301=comment 'IPVS MH scheduler'\nnet/netfilter/ipvs/Kconfig-302-\nnet/netfilter/ipvs/Kconfig:303:config IP_VS_MH_TAB_INDEX\nnet/netfilter/ipvs/Kconfig-304-\tint \"IPVS maglev hashing table index of size (the prime numbers)\"\n"
}

167/2

2026/07/07 03:15

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 73621
							output: 24
							thoughts: 23

Thoughts:

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Quick Verification & Next Steps**

Right, `IP_VS` is definitely the correct place to start. That checks out; I'm satisfied with that. Now, just to make absolutely certain, I'll quickly glance over `CONFIG_L2TP`. Need to ensure there are no subtle interactions or dependencies that I've missed. Might as well rule it out while it's fresh in my mind. Just a quick sanity check to avoid any potential headaches down the line.

168/2

2026/07/07 03:15

tool

grepper

Args:

{
  "Expression": "config L2TP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/l2tp/Kconfig-5-\nnet/l2tp/Kconfig:6:menuconfig L2TP\nnet/l2tp/Kconfig-7-\ttristate \"Layer Two Tunneling Protocol (L2TP)\"\n--\nnet/l2tp/Kconfig-35-\nnet/l2tp/Kconfig:36:config L2TP_DEBUGFS\nnet/l2tp/Kconfig-37-\ttristate \"L2TP debugfs support\"\n--\nnet/l2tp/Kconfig-48-\nnet/l2tp/Kconfig:49:config L2TP_V3\nnet/l2tp/Kconfig-50-\tbool \"L2TPv3 support\"\n--\nnet/l2tp/Kconfig-69-\nnet/l2tp/Kconfig:70:config L2TP_IP\nnet/l2tp/Kconfig-71-\ttristate \"L2TP IP encapsulation for L2TPv3\"\n--\nnet/l2tp/Kconfig-86-\nnet/l2tp/Kconfig:87:config L2TP_ETH\nnet/l2tp/Kconfig-88-\ttristate \"L2TP ethernet pseudowire support for L2TPv3\"\n"
}

169/2

2026/07/07 03:15

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 74106
							output: 25
							thoughts: 32

Thoughts:

Okay, here's my take on those thoughts, framed as my own:

**Verifying the VPN Configuration**

Alright, yep, that's right, `L2TP` is definitely the right protocol we're dealing with. Now, just to be absolutely certain and to make sure we're covering all the bases, I need to quickly double-check that the proper IPsec ESP support is enabled. Let me just confirm that `CONFIG_INET_ESP` and `CONFIG_INET6_ESP` are set as expected. Better safe than sorry when dealing with security, right? Making sure everything is locked down nice and tight is crucial.

170/2

2026/07/07 03:16

tool

grepper

Args:

{
  "Expression": "config INET_ESP",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/Kconfig=339=config INET_AH\n--\nnet/ipv4/Kconfig-353-\nnet/ipv4/Kconfig:354:config INET_ESP\nnet/ipv4/Kconfig-355-\ttristate \"IP: ESP transformation\"\n--\nnet/ipv4/Kconfig-368-\nnet/ipv4/Kconfig:369:config INET_ESP_OFFLOAD\nnet/ipv4/Kconfig-370-\ttristate \"IP: ESP transformation offload\"\n--\nnet/ipv4/Kconfig-381-\nnet/ipv4/Kconfig:382:config INET_ESPINTCP\nnet/ipv4/Kconfig-383-\tbool \"IP: ESP in TCP encapsulation (RFC 8229)\"\n"
}

171/2

2026/07/07 03:16

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 74511
							output: 25
							thoughts: 31

Thoughts:

Okay, here's my take on those thoughts, tailored for an expert audience:

**ESP and FOU Verification**

Alright, yep, confirming that `INET_ESP` and `INET6_ESP` are the appropriate defines for ESP over IPv4 and IPv6 respectively. Nothing to question there. Now, just to be absolutely certain – and because it’s a good habit – let’s quickly verify the configuration option for FOU. Specifically, I need to make sure `CONFIG_NET_FOU` is set appropriately, especially considering our project's requirements. This is a crucial area and a quick double-check never hurts, given how closely these things often interact.

172/2

2026/07/07 03:16

tool

grepper

Args:

{
  "Expression": "config NET_FOU",
  "PathPrefix": ""
}

Results:

{
  "Output": "net/ipv4/Kconfig=316=config NET_UDP_TUNNEL\n--\nnet/ipv4/Kconfig-320-\nnet/ipv4/Kconfig:321:config NET_FOU\nnet/ipv4/Kconfig-322-\ttristate \"IP: Foo (IP protocols) over UDP\"\n--\nnet/ipv4/Kconfig-329-\nnet/ipv4/Kconfig:330:config NET_FOU_IP_TUNNELS\nnet/ipv4/Kconfig-331-\tbool \"IP: FOU encapsulation of IP tunnels\"\n"
}

173/2

2026/07/07 03:16

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 74866
							output: 24
							thoughts: 24

Thoughts:

Okay, here's my summary, presented as a stream of thought:

**Confirming and Cross-Referencing**

Alright, yep, that `NET_FOU` setting, the one we've been looking at – that's definitely correct. No need to second-guess that. Good. Now, just to be completely thorough, let's circle back and quickly verify that `CONFIG_GENEVE` option. I want to make sure there are no downstream implications or overlooked dependencies. It's always best practice to double-check related configurations, even when you're reasonably sure, just to keep things airtight. Let's see...

174/2

2026/07/07 03:16

tool

grepper

Args:

{
  "Expression": "config GENEVE",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=230=config VXLAN\n--\ndrivers/net/Kconfig-244-\ndrivers/net/Kconfig:245:config GENEVE\ndrivers/net/Kconfig-246-\ttristate \"Generic Network Virtualization Encapsulation\"\n"
}

175/2

2026/07/07 03:16

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 75133
							output: 23
							thoughts: 22

Thoughts:

Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person:

**Confirming and Cross-Referencing Configuration**

Right, `GENEVE` is definitely the protocol we're working with here. That's settled. But I always like to be thorough, especially when it comes to networking and potential dependencies. Let's just quickly verify the state of `CONFIG_VXLAN` to ensure there are no unforeseen conflicts or interactions. A quick sanity check now could save a headache later. Just making sure everything lines up as it should.

176/2

2026/07/07 03:16

tool

grepper

Args:

{
  "Expression": "config VXLAN",
  "PathPrefix": ""
}

Results:

{
  "Output": "drivers/net/Kconfig=216=config IPVTAP\n--\ndrivers/net/Kconfig-229-\ndrivers/net/Kconfig:230:config VXLAN\ndrivers/net/Kconfig-231-\ttristate \"Virtual eXtensible Local Area Network (VXLAN)\"\n"
}

177/2

2026/07/07 03:16

llm

patch-evaluator

Model:

gemini-3.1-pro-preview

Args:

null

Results:

null

Tokens:

							input: 75386
							output: 654
							thoughts: 16

Thoughts:

Here's your summary:

**VXLAN Confirmation and Result Finalization**

Okay, yes, I've confirmed it. My assessment of the situation points directly to `VXLAN`. This is the correct solution given the parameters. I'm satisfied with the findings. Now, I'm ready to finalize these results and present them with confidence. It's time to put a bow on this.

178/2

2026/07/07 03:16

tool

set-results

Args:

{
  "EnableConfigs": [
    "VXLAN",
    "GENEVE",
    "NET_FOU",
    "INET_ESP",
    "INET6_ESP",
    "L2TP",
    "IP_VS",
    "AMT",
    "WIREGUARD",
    "6LOWPAN_NHC_UDP",
    "NF_NAT_SNMP_BASIC",
    "NET_ACT_CSUM",
    "RDMA_RXE",
    "NETDEVSIM",
    "INET_PSP"
  ],
  "FocusSymbols": [
    "__udp_gso_segment",
    "udp_gro_complete",
    "udp4_gro_complete",
    "udp6_gro_complete",
    "udp_tunnel_xmit_skb",
    "udp_tunnel6_xmit_skb",
    "__skb_udp_tunnel_segment",
    "udp_gro_receive_segment",
    "fou_build_udp",
    "fou6_build_udp",
    "esp_output_udp_encap",
    "esp6_output_udp_encap",
    "l2tp_xmit_core",
    "ipvs_gue_encap",
    "tso_build_hdr",
    "skb_segment",
    "amt_send_discovery",
    "nsim_do_psp",
    "psp_write_headers",
    "nat_keepalive_send",
    "tcf_csum_ipv4_udp",
    "tcf_csum_ipv6_udp",
    "nf_nat_mangle_udp_packet",
    "udp_error",
    "snmp_translate",
    "udp_uncompress",
    "prepare_skb_header",
    "rdma_build_skb",
    "rxe_udp_encap_recv",
    "efx_gen_tun_header_udp",
    "i40e_tso",
    "iavf_tso",
    "ice_tso",
    "idpf_tso",
    "otx2_sqe_add_ext",
    "mlx5e_shampo_update_ipv4_udp_hdr",
    "mlx5e_shampo_update_ipv6_udp_hdr",
    "inet_rtm_getroute_build_skb",
    "fill_packet_ipv4",
    "fill_packet_ipv6"
  ],
  "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.",
  "WorthFuzzing": true
}

Results:

{
  "EnableConfigs": [
    "VXLAN",
    "GENEVE",
    "NET_FOU",
    "INET_ESP",
    "INET6_ESP",
    "L2TP",
    "IP_VS",
    "AMT",
    "WIREGUARD",
    "6LOWPAN_NHC_UDP",
    "NF_NAT_SNMP_BASIC",
    "NET_ACT_CSUM",
    "RDMA_RXE",
    "NETDEVSIM",
    "INET_PSP"
  ],
  "FocusSymbols": [
    "__udp_gso_segment",
    "udp_gro_complete",
    "udp4_gro_complete",
    "udp6_gro_complete",
    "udp_tunnel_xmit_skb",
    "udp_tunnel6_xmit_skb",
    "__skb_udp_tunnel_segment",
    "udp_gro_receive_segment",
    "fou_build_udp",
    "fou6_build_udp",
    "esp_output_udp_encap",
    "esp6_output_udp_encap",
    "l2tp_xmit_core",
    "ipvs_gue_encap",
    "tso_build_hdr",
    "skb_segment",
    "amt_send_discovery",
    "nsim_do_psp",
    "psp_write_headers",
    "nat_keepalive_send",
    "tcf_csum_ipv4_udp",
    "tcf_csum_ipv6_udp",
    "nf_nat_mangle_udp_packet",
    "udp_error",
    "snmp_translate",
    "udp_uncompress",
    "prepare_skb_header",
    "rdma_build_skb",
    "rxe_udp_encap_recv",
    "efx_gen_tun_header_udp",
    "i40e_tso",
    "iavf_tso",
    "ice_tso",
    "idpf_tso",
    "otx2_sqe_add_ext",
    "mlx5e_shampo_update_ipv4_udp_hdr",
    "mlx5e_shampo_update_ipv6_udp_hdr",
    "inet_rtm_getroute_build_skb",
    "fill_packet_ipv4",
    "fill_packet_ipv6"
  ],
  "Reasoning": "The patch introduces `udp_set_len_short`, `udp_get_len_short`, and `udp_get_len` functions and applies them across various networking drivers and core networking code (UDP, UDP offload, GRO, GSO, TSO, IPv4, IPv6, VXLAN, GENEVE). This is related to supporting BIG TCP (GSO sizes larger than 64K) over UDP tunnels. The patch modifies reachable core kernel logic and drivers, so it is worth fuzzing.",
  "WorthFuzzing": true
}