AI Trajectory


Trajectory: (Expand/Collapse All)
Seq Timestamp Type Name Duration
0/0 2026/08/10 22:37 flow patch-triage
2m Args: 
null

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "KMSANReasoning": "",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the AF_XDP TX metadata implementation to check for the XDP_TX_METADATA flag in the descriptor options before returning the metadata pointer. It updates the xsk_buff_get_metadata and xp_raw_get_ctx helpers and their callers. However, AF_XDP TX metadata and zero-copy are only supported by a few specific hardware drivers: igc, mlx5, stmmac, and idpf. None of these drivers are virtual, nor are they emulated in standard QEMU environments used by syzkaller. The veth and virtio_net drivers, which are reachable in virtualized environments, do not support AF_XDP TX metadata and do not call the modified functions. Therefore, the modified code paths are impossible to reach in virtualized environments.",
  "WorthFuzzing": false
}
1/1 2026/08/10 22:37 action read-patch-diff
0m Args: 
null

Results: 
{
  "PatchDiff": "commit eb29c10607e473cababd916af00f73c5fb9a98e9\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 10 22:37:48 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c\nindex 8b9ce7cbfff9b..1fb5f3cbe93c5 100644\n--- a/drivers/net/ethernet/intel/igc/igc_main.c\n+++ b/drivers/net/ethernet/intel/igc/igc_main.c\n@@ -3071,7 +3071,8 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)\n \t\tolinfo_status = xdp_desc.len \u003c\u003c IGC_ADVTXD_PAYLEN_SHIFT;\n \n \t\tdma = xsk_buff_raw_get_dma(pool, xdp_desc.addr);\n-\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr);\n+\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr,\n+\t\t\t\t\t     xdp_desc.options);\n \t\txsk_buff_raw_dma_sync_for_device(pool, dma, xdp_desc.len);\n \t\tbi = \u0026ring-\u003etx_buffer_info[ntu];\n \ndiff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c\nindex 3d19dad8f8688..d194eeddd7b55 100644\n--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c\n+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c\n@@ -99,7 +99,7 @@ bool mlx5e_xsk_tx(struct mlx5e_xdpsq *sq, unsigned int budget)\n \t\txdptxd.dma_addr = xsk_buff_raw_get_dma(pool, desc.addr);\n \t\txdptxd.data = xsk_buff_raw_get_data(pool, desc.addr);\n \t\txdptxd.len = desc.len;\n-\t\tmeta = xsk_buff_get_metadata(pool, desc.addr);\n+\t\tmeta = xsk_buff_get_metadata(pool, desc.addr, desc.options);\n \n \t\txsk_buff_raw_dma_sync_for_device(pool, xdptxd.dma_addr, xdptxd.len);\n \ndiff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\nindex b2b7d0242dd3c..6e9d4cb336eee 100644\n--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c\n@@ -2714,16 +2714,10 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)\n \t\tif (!xsk_tx_peek_desc(pool, \u0026xdp_desc))\n \t\t\tbreak;\n \n-\t\tif (priv-\u003eest \u0026\u0026 priv-\u003eest-\u003eenable \u0026\u0026\n-\t\t    priv-\u003eest-\u003emax_sdu[queue] \u0026\u0026\n-\t\t    xdp_desc.len \u003e priv-\u003eest-\u003emax_sdu[queue]) {\n-\t\t\tpriv-\u003exstats.max_sdu_txq_drop[queue]++;\n-\t\t\tcontinue;\n-\t\t}\n-\n \t\ttx_desc = stmmac_get_tx_desc(priv, tx_q, entry);\n \t\tdma_addr = xsk_buff_raw_get_dma(pool, xdp_desc.addr);\n-\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr);\n+\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr,\n+\t\t\t\t\t     xdp_desc.options);\n \t\txsk_buff_raw_dma_sync_for_device(pool, dma_addr, xdp_desc.len);\n \n \t\t/* To return XDP buffer to XSK pool, we simple call\ndiff --git a/include/net/libeth/xsk.h b/include/net/libeth/xsk.h\nindex 5dcc0d7f65b76..a452b7828ce4e 100644\n--- a/include/net/libeth/xsk.h\n+++ b/include/net/libeth/xsk.h\n@@ -196,7 +196,7 @@ __libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\n \tstruct libeth_xdp_tx_desc desc;\n \tstruct xdp_desc_ctx ctx;\n \n-\tctx = xsk_buff_raw_get_ctx(sq-\u003epool, xdesc-\u003eaddr);\n+\tctx = xsk_buff_raw_get_ctx(sq-\u003epool, xdesc-\u003eaddr, xdesc-\u003eoptions);\n \tdesc = (typeof(desc)){\n \t\t.addr\t= ctx.dma,\n \t\t__libeth_xdp_tx_len(xdesc-\u003elen),\ndiff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h\nindex b344789f5df83..d94aeb506379c 100644\n--- a/include/net/xdp_sock_drv.h\n+++ b/include/net/xdp_sock_drv.h\n@@ -240,6 +240,7 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)\n  * xsk_buff_raw_get_ctx - get \u0026xdp_desc context\n  * @pool: XSk buff pool desc address belongs to\n  * @addr: desc address (from userspace)\n+ * @options: desc options (from userspace)\n  *\n  * Wrapper for xp_raw_get_ctx() to be used in drivers, see its kdoc for\n  * details.\n@@ -248,9 +249,9 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)\n  * pointer, if it is present (initialized to %NULL otherwise).\n  */\n static inline struct xdp_desc_ctx\n-xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)\n+xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)\n {\n-\treturn xp_raw_get_ctx(pool, addr);\n+\treturn xp_raw_get_ctx(pool, addr, options);\n }\n \n #define XDP_TXMD_FLAGS_VALID ( \\\n@@ -318,18 +319,20 @@ xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\n }\n \n static inline struct xsk_tx_metadata *\n-__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data)\n+__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\n+\t\t\tunsigned int options)\n {\n-\tif (!pool-\u003etx_metadata_len)\n+\tif (!pool-\u003etx_metadata_len || !(options \u0026 XDP_TX_METADATA))\n \t\treturn NULL;\n \n \treturn data - pool-\u003etx_metadata_len;\n }\n \n static inline struct xsk_tx_metadata *\n-xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr)\n+xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)\n {\n-\treturn __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr));\n+\treturn __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr),\n+\t\t\t\t       options);\n }\n \n static inline void xsk_buff_dma_sync_for_cpu(struct xdp_buff *xdp)\n@@ -510,7 +513,7 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)\n }\n \n static inline struct xdp_desc_ctx\n-xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)\n+xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)\n {\n \treturn (struct xdp_desc_ctx){ };\n }\n@@ -530,13 +533,14 @@ xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\n }\n \n static inline struct xsk_tx_metadata *\n-__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data)\n+__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\n+\t\t\tunsigned int options)\n {\n \treturn NULL;\n }\n \n static inline struct xsk_tx_metadata *\n-xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr)\n+xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)\n {\n \treturn NULL;\n }\ndiff --git a/include/net/xsk_buff_pool.h b/include/net/xsk_buff_pool.h\nindex 2bb1d122b1bc6..a7df573784fd6 100644\n--- a/include/net/xsk_buff_pool.h\n+++ b/include/net/xsk_buff_pool.h\n@@ -154,7 +154,8 @@ struct xdp_desc_ctx {\n \tstruct xsk_tx_metadata *meta;\n };\n \n-struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr);\n+struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\n+\t\t\t\t   u32 options);\n \n static inline dma_addr_t xp_get_dma(struct xdp_buff_xsk *xskb)\n {\ndiff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h\nindex 23a0627814687..50d67df78911f 100644\n--- a/include/uapi/linux/if_xdp.h\n+++ b/include/uapi/linux/if_xdp.h\n@@ -149,6 +149,7 @@ struct xsk_tx_metadata {\n \t\t\t__u16 csum_start;\n \t\t\t/* Offset from csum_start where checksum should be stored. */\n \t\t\t__u16 csum_offset;\n+\t\t\t__u32 reserved;\n \n \t\t\t/* XDP_TXMD_FLAGS_LAUNCH_TIME */\n \t\t\t/* Launch time in nanosecond against the PTP HW Clock */\ndiff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c\nindex 78c14f1063957..9d2d94f1fb759 100644\n--- a/net/xdp/xsk_buff_pool.c\n+++ b/net/xdp/xsk_buff_pool.c\n@@ -763,6 +763,7 @@ EXPORT_SYMBOL(xp_raw_get_dma);\n  * xp_raw_get_ctx - get \u0026xdp_desc context\n  * @pool: XSk buff pool desc address belongs to\n  * @addr: desc address (from userspace)\n+ * @options: desc options (from userspace)\n  *\n  * Helper for getting desc's DMA address and metadata pointer, if present.\n  * Saves one call on hotpath and double calculation of the actual address.\n@@ -771,14 +772,16 @@ EXPORT_SYMBOL(xp_raw_get_dma);\n  * Return: new \u0026xdp_desc_ctx struct containing desc's DMA address and metadata\n  * pointer, if it is present (initialized to %NULL otherwise).\n  */\n-struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)\n+struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\n+\t\t\t\t   u32 options)\n {\n \tstruct xdp_desc_ctx ret;\n \n \taddr = __xp_raw_get_addr(pool, addr);\n \n \tret.dma = __xp_raw_get_dma(pool, addr);\n-\tret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr));\n+\tret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr),\n+\t\t\t\t\t   options);\n \n \treturn ret;\n }\ndiff --git a/tools/include/uapi/linux/if_xdp.h b/tools/include/uapi/linux/if_xdp.h\nindex 23a0627814687..50d67df78911f 100644\n--- a/tools/include/uapi/linux/if_xdp.h\n+++ b/tools/include/uapi/linux/if_xdp.h\n@@ -149,6 +149,7 @@ struct xsk_tx_metadata {\n \t\t\t__u16 csum_start;\n \t\t\t/* Offset from csum_start where checksum should be stored. */\n \t\t\t__u16 csum_offset;\n+\t\t\t__u32 reserved;\n \n \t\t\t/* XDP_TXMD_FLAGS_LAUNCH_TIME */\n \t\t\t/* Launch time in nanosecond against the PTP HW Clock */\n"
}
2/1 2026/08/10 22:37 agent patch-evaluator
2m Model: 
best-expensive

Args: 
null

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the AF_XDP TX metadata implementation to check for the XDP_TX_METADATA flag in the descriptor options before returning the metadata pointer. It updates the xsk_buff_get_metadata and xp_raw_get_ctx helpers and their callers. However, AF_XDP TX metadata and zero-copy are only supported by a few specific hardware drivers: igc, mlx5, stmmac, and idpf. None of these drivers are virtual, nor are they emulated in standard QEMU environments used by syzkaller. The veth and virtio_net drivers, which are reachable in virtualized environments, do not support AF_XDP TX metadata and do not call the modified functions. Therefore, the modified code paths are impossible to reach in virtualized environments.",
  "WorthFuzzing": false
}

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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 eb29c10607e473cababd916af00f73c5fb9a98e9
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 10 22:37:48 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 8b9ce7cbfff9b..1fb5f3cbe93c5 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -3071,7 +3071,8 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
 		olinfo_status = xdp_desc.len << IGC_ADVTXD_PAYLEN_SHIFT;
 
 		dma = xsk_buff_raw_get_dma(pool, xdp_desc.addr);
-		meta = xsk_buff_get_metadata(pool, xdp_desc.addr);
+		meta = xsk_buff_get_metadata(pool, xdp_desc.addr,
+					     xdp_desc.options);
 		xsk_buff_raw_dma_sync_for_device(pool, dma, xdp_desc.len);
 		bi = &ring->tx_buffer_info[ntu];
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
index 3d19dad8f8688..d194eeddd7b55 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c
@@ -99,7 +99,7 @@ bool mlx5e_xsk_tx(struct mlx5e_xdpsq *sq, unsigned int budget)
 		xdptxd.dma_addr = xsk_buff_raw_get_dma(pool, desc.addr);
 		xdptxd.data = xsk_buff_raw_get_data(pool, desc.addr);
 		xdptxd.len = desc.len;
-		meta = xsk_buff_get_metadata(pool, desc.addr);
+		meta = xsk_buff_get_metadata(pool, desc.addr, desc.options);
 
 		xsk_buff_raw_dma_sync_for_device(pool, xdptxd.dma_addr, xdptxd.len);
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b2b7d0242dd3c..6e9d4cb336eee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2714,16 +2714,10 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
 		if (!xsk_tx_peek_desc(pool, &xdp_desc))
 			break;
 
-		if (priv->est && priv->est->enable &&
-		    priv->est->max_sdu[queue] &&
-		    xdp_desc.len > priv->est->max_sdu[queue]) {
-			priv->xstats.max_sdu_txq_drop[queue]++;
-			continue;
-		}
-
 		tx_desc = stmmac_get_tx_desc(priv, tx_q, entry);
 		dma_addr = xsk_buff_raw_get_dma(pool, xdp_desc.addr);
-		meta = xsk_buff_get_metadata(pool, xdp_desc.addr);
+		meta = xsk_buff_get_metadata(pool, xdp_desc.addr,
+					     xdp_desc.options);
 		xsk_buff_raw_dma_sync_for_device(pool, dma_addr, xdp_desc.len);
 
 		/* To return XDP buffer to XSK pool, we simple call
diff --git a/include/net/libeth/xsk.h b/include/net/libeth/xsk.h
index 5dcc0d7f65b76..a452b7828ce4e 100644
--- a/include/net/libeth/xsk.h
+++ b/include/net/libeth/xsk.h
@@ -196,7 +196,7 @@ __libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,
 	struct libeth_xdp_tx_desc desc;
 	struct xdp_desc_ctx ctx;
 
-	ctx = xsk_buff_raw_get_ctx(sq->pool, xdesc->addr);
+	ctx = xsk_buff_raw_get_ctx(sq->pool, xdesc->addr, xdesc->options);
 	desc = (typeof(desc)){
 		.addr	= ctx.dma,
 		__libeth_xdp_tx_len(xdesc->len),
diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h
index b344789f5df83..d94aeb506379c 100644
--- a/include/net/xdp_sock_drv.h
+++ b/include/net/xdp_sock_drv.h
@@ -240,6 +240,7 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)
  * xsk_buff_raw_get_ctx - get &xdp_desc context
  * @pool: XSk buff pool desc address belongs to
  * @addr: desc address (from userspace)
+ * @options: desc options (from userspace)
  *
  * Wrapper for xp_raw_get_ctx() to be used in drivers, see its kdoc for
  * details.
@@ -248,9 +249,9 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)
  * pointer, if it is present (initialized to %NULL otherwise).
  */
 static inline struct xdp_desc_ctx
-xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)
+xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)
 {
-	return xp_raw_get_ctx(pool, addr);
+	return xp_raw_get_ctx(pool, addr, options);
 }
 
 #define XDP_TXMD_FLAGS_VALID ( \
@@ -318,18 +319,20 @@ xsk_tx_metadata_request(const struct xsk_buff_pool *pool,
 }
 
 static inline struct xsk_tx_metadata *
-__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data)
+__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,
+			unsigned int options)
 {
-	if (!pool->tx_metadata_len)
+	if (!pool->tx_metadata_len || !(options & XDP_TX_METADATA))
 		return NULL;
 
 	return data - pool->tx_metadata_len;
 }
 
 static inline struct xsk_tx_metadata *
-xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr)
+xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)
 {
-	return __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr));
+	return __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr),
+				       options);
 }
 
 static inline void xsk_buff_dma_sync_for_cpu(struct xdp_buff *xdp)
@@ -510,7 +513,7 @@ static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)
 }
 
 static inline struct xdp_desc_ctx
-xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)
+xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)
 {
 	return (struct xdp_desc_ctx){ };
 }
@@ -530,13 +533,14 @@ xsk_tx_metadata_request(const struct xsk_buff_pool *pool,
 }
 
 static inline struct xsk_tx_metadata *
-__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data)
+__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,
+			unsigned int options)
 {
 	return NULL;
 }
 
 static inline struct xsk_tx_metadata *
-xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr)
+xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)
 {
 	return NULL;
 }
diff --git a/include/net/xsk_buff_pool.h b/include/net/xsk_buff_pool.h
index 2bb1d122b1bc6..a7df573784fd6 100644
--- a/include/net/xsk_buff_pool.h
+++ b/include/net/xsk_buff_pool.h
@@ -154,7 +154,8 @@ struct xdp_desc_ctx {
 	struct xsk_tx_metadata *meta;
 };
 
-struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr);
+struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,
+				   u32 options);
 
 static inline dma_addr_t xp_get_dma(struct xdp_buff_xsk *xskb)
 {
diff --git a/include/uapi/linux/if_xdp.h b/include/uapi/linux/if_xdp.h
index 23a0627814687..50d67df78911f 100644
--- a/include/uapi/linux/if_xdp.h
+++ b/include/uapi/linux/if_xdp.h
@@ -149,6 +149,7 @@ struct xsk_tx_metadata {
 			__u16 csum_start;
 			/* Offset from csum_start where checksum should be stored. */
 			__u16 csum_offset;
+			__u32 reserved;
 
 			/* XDP_TXMD_FLAGS_LAUNCH_TIME */
 			/* Launch time in nanosecond against the PTP HW Clock */
diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
index 78c14f1063957..9d2d94f1fb759 100644
--- a/net/xdp/xsk_buff_pool.c
+++ b/net/xdp/xsk_buff_pool.c
@@ -763,6 +763,7 @@ EXPORT_SYMBOL(xp_raw_get_dma);
  * xp_raw_get_ctx - get &xdp_desc context
  * @pool: XSk buff pool desc address belongs to
  * @addr: desc address (from userspace)
+ * @options: desc options (from userspace)
  *
  * Helper for getting desc's DMA address and metadata pointer, if present.
  * Saves one call on hotpath and double calculation of the actual address.
@@ -771,14 +772,16 @@ EXPORT_SYMBOL(xp_raw_get_dma);
  * Return: new &xdp_desc_ctx struct containing desc's DMA address and metadata
  * pointer, if it is present (initialized to %NULL otherwise).
  */
-struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr)
+struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,
+				   u32 options)
 {
 	struct xdp_desc_ctx ret;
 
 	addr = __xp_raw_get_addr(pool, addr);
 
 	ret.dma = __xp_raw_get_dma(pool, addr);
-	ret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr));
+	ret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr),
+					   options);
 
 	return ret;
 }
diff --git a/tools/include/uapi/linux/if_xdp.h b/tools/include/uapi/linux/if_xdp.h
index 23a0627814687..50d67df78911f 100644
--- a/tools/include/uapi/linux/if_xdp.h
+++ b/tools/include/uapi/linux/if_xdp.h
@@ -149,6 +149,7 @@ struct xsk_tx_metadata {
 			__u16 csum_start;
 			/* Offset from csum_start where checksum should be stored. */
 			__u16 csum_offset;
+			__u32 reserved;
 
 			/* XDP_TXMD_FLAGS_LAUNCH_TIME */
 			/* Launch time in nanosecond against the PTP HW Clock */

3/2 2026/08/10 22:37 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 5456
							output: 22
							thoughts: 616

Thoughts: 
**Analyzing the Scope and Reachability of this XDP/AF_XDP Patch**

Okay, so I'm looking at this patch that tweaks the XDP and AF_XDP (xsk) code. Specifically, it's modifying `xsk_buff_get_metadata` and `xp_raw_get_ctx` to accept an `options` parameter. This parameter is getting passed from userspace through `xdp_desc.options`, which is interesting. The code then checks `options & XDP_TX_METADATA` before actually returning the metadata pointer. Smart.

They're also adding a `__u32 reserved;` field to `struct xsk_tx_metadata` in `if_xdp.h`. And there's some cleanup in `stmmac_xdp_xmit_zc`, removing some code related to `priv->est->max_sdu[queue]`.

Now, the important question for me is: what's the reachability of these changes? Where can they be triggered, and what's the potential attack surface? I see the changes are touching several drivers: Intel's `igc`, Mellanox's `mlx5`, and STMicro's `stmmac`. Plus, it's altering some core networking headers and files, including `xsk.h`, `xdp_sock_drv.h`, and `xsk_buff_pool.c`.

The core change, as I see it, is in `__xsk_buff_get_metadata`: It now has an `options` parameter and the crucial check `!(options & XDP_TX_METADATA)`. This is a clear indicator that the changes are tied to the `XDP_TX_METADATA` flag. That's good.

So, AF_XDP sockets are definitely involved here, as `XDP_TX_METADATA` is a flag related to AF_XDP. AF_XDP is a central networking component. I'm thinking I can likely fuzz this with syzkaller, using veth or other virtual interfaces. But wait a minute. `xsk_buff_get_metadata` is also *used* in driver code! This warrants a deeper look.

I need to confirm if those functions are used by virtual drivers, like veth or macvlan. If so, that opens up a much more accessible and potentially interesting attack surface. I'll need to check the codebase to see if these functions are getting called by any of those virtual drivers. That's the next step.

4/2 2026/08/10 22:37 tool grepper
0m Args: 
{
  "Expression": "xsk_buff_get_metadata"
}

Results: 
{
  "Output": "drivers/net/ethernet/intel/igc/igc_main.c=3034=static void igc_xdp_xmit_zc(struct igc_ring *ring)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-3073-\t\tdma = xsk_buff_raw_get_dma(pool, xdp_desc.addr);\ndrivers/net/ethernet/intel/igc/igc_main.c:3074:\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr,\ndrivers/net/ethernet/intel/igc/igc_main.c-3075-\t\t\t\t\t     xdp_desc.options);\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c=66=bool mlx5e_xsk_tx(struct mlx5e_xdpsq *sq, unsigned int budget)\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c-101-\t\txdptxd.len = desc.len;\ndrivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c:102:\t\tmeta = xsk_buff_get_metadata(pool, desc.addr, desc.options);\ndrivers/net/ethernet/mellanox/mlx5/core/en/xsk/tx.c-103-\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=2681=static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2718-\t\tdma_addr = xsk_buff_raw_get_dma(pool, xdp_desc.addr);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2719:\t\tmeta = xsk_buff_get_metadata(pool, xdp_desc.addr,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2720-\t\t\t\t\t     xdp_desc.options);\n--\ninclude/net/xdp_sock_drv.h=321=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:322:__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\ninclude/net/xdp_sock_drv.h-323-\t\t\tunsigned int options)\n--\ninclude/net/xdp_sock_drv.h=331=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:332:xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-333-{\ninclude/net/xdp_sock_drv.h:334:\treturn __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr),\ninclude/net/xdp_sock_drv.h-335-\t\t\t\t       options);\n--\ninclude/net/xdp_sock_drv.h=535=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:536:__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\ninclude/net/xdp_sock_drv.h-537-\t\t\tunsigned int options)\n--\ninclude/net/xdp_sock_drv.h=542=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:543:xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-544-{\n--\nnet/xdp/xsk_buff_pool.c=775=struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\n--\nnet/xdp/xsk_buff_pool.c-782-\tret.dma = __xp_raw_get_dma(pool, addr);\nnet/xdp/xsk_buff_pool.c:783:\tret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr),\nnet/xdp/xsk_buff_pool.c-784-\t\t\t\t\t   options);\n"
}
5/2 2026/08/10 22:37 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 7838
							output: 21
							thoughts: 45

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

**Analyzing `xsk_buff_get_metadata` Usage**

Alright, let's see... it appears that `xsk_buff_get_metadata` is really only being utilized within the `igc`, `mlx5`, and `stmmac` drivers. That's a pretty limited scope, all things considered. It's good to know where it is *and isn't* used. Now, hold on a second... is that *truly* the complete picture? Didn't we have something else that touched XDP context? What about `xp_raw_get_ctx`? I need to quickly recall if there are any subtle interactions or overlapping uses that I am forgetting. Let me quickly double-check that.

6/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "xp_raw_get_ctx"
}

Results: 
{
  "Output": "include/net/xdp_sock_drv.h=234=static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)\n--\ninclude/net/xdp_sock_drv.h-244- *\ninclude/net/xdp_sock_drv.h:245: * Wrapper for xp_raw_get_ctx() to be used in drivers, see its kdoc for\ninclude/net/xdp_sock_drv.h-246- * details.\n--\ninclude/net/xdp_sock_drv.h=252=xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-253-{\ninclude/net/xdp_sock_drv.h:254:\treturn xp_raw_get_ctx(pool, addr, options);\ninclude/net/xdp_sock_drv.h-255-}\n--\ninclude/net/xsk_buff_pool.h=152=struct xdp_desc_ctx {\n--\ninclude/net/xsk_buff_pool.h-156-\ninclude/net/xsk_buff_pool.h:157:struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\ninclude/net/xsk_buff_pool.h-158-\t\t\t\t   u32 options);\n--\nnet/xdp/xsk_buff_pool.c=760=EXPORT_SYMBOL(xp_raw_get_dma);\n--\nnet/xdp/xsk_buff_pool.c-762-/**\nnet/xdp/xsk_buff_pool.c:763: * xp_raw_get_ctx - get \u0026xdp_desc context\nnet/xdp/xsk_buff_pool.c-764- * @pool: XSk buff pool desc address belongs to\n--\nnet/xdp/xsk_buff_pool.c-774- */\nnet/xdp/xsk_buff_pool.c:775:struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\nnet/xdp/xsk_buff_pool.c-776-\t\t\t\t   u32 options)\n--\nnet/xdp/xsk_buff_pool.c-787-}\nnet/xdp/xsk_buff_pool.c:788:EXPORT_SYMBOL(xp_raw_get_ctx);\n"
}
7/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 8738
							output: 24
							thoughts: 44

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

**Digging into the XDP Context Retrieval**

Right, so `xp_raw_get_ctx` is wrapped by `xsk_buff_raw_get_ctx`. That's an interesting layering. My initial thought is to trace the usage of `xsk_buff_raw_get_ctx` itself. Knowing where *that* is used is going to be key to understanding the overall data flow and how the XDP context is being accessed within this XSK buffer system. It's the logical next step to figure out the larger picture of how we get the context. Let's see what the call sites reveal...

8/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "xsk_buff_raw_get_ctx"
}

Results: 
{
  "Output": "include/net/libeth/xsk.h=191=__libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\n--\ninclude/net/libeth/xsk.h-198-\ninclude/net/libeth/xsk.h:199:\tctx = xsk_buff_raw_get_ctx(sq-\u003epool, xdesc-\u003eaddr, xdesc-\u003eoptions);\ninclude/net/libeth/xsk.h-200-\tdesc = (typeof(desc)){\n--\ninclude/net/xdp_sock_drv.h=234=static inline void *xsk_buff_raw_get_data(struct xsk_buff_pool *pool, u64 addr)\n--\ninclude/net/xdp_sock_drv.h-239-/**\ninclude/net/xdp_sock_drv.h:240: * xsk_buff_raw_get_ctx - get \u0026xdp_desc context\ninclude/net/xdp_sock_drv.h-241- * @pool: XSk buff pool desc address belongs to\n--\ninclude/net/xdp_sock_drv.h=251=static inline struct xdp_desc_ctx\ninclude/net/xdp_sock_drv.h:252:xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-253-{\n--\ninclude/net/xdp_sock_drv.h=515=static inline struct xdp_desc_ctx\ninclude/net/xdp_sock_drv.h:516:xsk_buff_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-517-{\n"
}
9/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 9432
							output: 29
							thoughts: 72

Thoughts: 
Here's my summary, as the expert:

**Investigating the Data Flow in the eBPF/XDP Network Stack**

Alright, let's trace this down. I see that `xsk_buff_raw_get_ctx` is called within `__libeth_xsk_xmit_fill_buf_md`. I know `xsk_buff_raw_get_ctx` is important for retrieving buffer context information within the XDP/XSK framework, so any place that function is involved is a key area of interest. Now, I need to understand the larger context. My next move is clear: I need to quickly identify all the call sites of `__libeth_xsk_xmit_fill_buf_md` itself. This will provide a more complete picture of how the data is being handled and where this specific context retrieval fits into the overall packet transmission process within the libeth XSK implementation. Understanding this will highlight the potential impact of any changes or debugging steps I might take.

10/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "__libeth_xsk_xmit_fill_buf_md"
}

Results: 
{
  "Output": "include/net/libeth/xsk.h=174=static const struct xsk_tx_metadata_ops __libeth_xsktmo = {\n--\ninclude/net/libeth/xsk.h-178-/**\ninclude/net/libeth/xsk.h:179: * __libeth_xsk_xmit_fill_buf_md - internal helper to prepare XSk xmit w/meta\ninclude/net/libeth/xsk.h-180- * @xdesc: \u0026xdp_desc from the XSk buffer pool\n--\ninclude/net/libeth/xsk.h=190=static __always_inline struct libeth_xdp_tx_desc\ninclude/net/libeth/xsk.h:191:__libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\ninclude/net/libeth/xsk.h-192-\t\t\t      const struct libeth_xdpsq *sq,\n--\ninclude/net/libeth/xsk.h=247=libeth_xsk_xmit_fill_buf(struct libeth_xdp_tx_frame frm, u32 i,\n--\ninclude/net/libeth/xsk.h-252-\tif (priv)\ninclude/net/libeth/xsk.h:253:\t\tdesc = __libeth_xsk_xmit_fill_buf_md(\u0026frm.desc, sq, priv);\ninclude/net/libeth/xsk.h-254-\telse\n"
}
11/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 10138
							output: 26
							thoughts: 18

Thoughts: 
Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Where Does `libeth_xsk_xmit_fill_buf` Fit In?**

Okay, so I'm thinking about `libeth_xsk_xmit_fill_buf`. It's pretty fundamental, right? That function is crucial to the eBPF datapath. Now, I need to jog my memory to remember *exactly* where it's being used. It's obviously tied to the transmission path, filling the buffer to get packets out.

I need to quickly recall the typical XDP/eBPF data flow. I believe I'm using `libeth`, which handles the Ethernet header generation and manipulation. The `xsk_xmit` path from the XDP program. So, it should be in the context of XDP sockets (XSK) on the transmit side, which feeds data to the driver ring. Basically, it’s the bridge between the application's data and the network interface card. I'd imagine it would be involved in assembling the frame and handing it over. I need to refresh my memory on the implementation details around that function, and how it interacts with the other functions in the library for memory management. Is it directly called by the XDP program, or is there another function in between? I should probably review the implementation and call graphs to be certain, to ensure my assumptions are sound.

12/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "libeth_xsk_xmit_fill_buf"
}

Results: 
{
  "Output": "include/net/libeth/xsk.h=174=static const struct xsk_tx_metadata_ops __libeth_xsktmo = {\n--\ninclude/net/libeth/xsk.h-178-/**\ninclude/net/libeth/xsk.h:179: * __libeth_xsk_xmit_fill_buf_md - internal helper to prepare XSk xmit w/meta\ninclude/net/libeth/xsk.h-180- * @xdesc: \u0026xdp_desc from the XSk buffer pool\n--\ninclude/net/libeth/xsk.h-183- *\ninclude/net/libeth/xsk.h:184: * Same as __libeth_xsk_xmit_fill_buf(), but requests metadata pointer and\ninclude/net/libeth/xsk.h-185- * fills additional fields in \u0026libeth_xdp_tx_desc to ask for metadata offload.\n--\ninclude/net/libeth/xsk.h=190=static __always_inline struct libeth_xdp_tx_desc\ninclude/net/libeth/xsk.h:191:__libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\ninclude/net/libeth/xsk.h-192-\t\t\t      const struct libeth_xdpsq *sq,\n--\ninclude/net/libeth/xsk.h-215-/**\ninclude/net/libeth/xsk.h:216: * __libeth_xsk_xmit_fill_buf - internal helper to prepare XSk xmit w/o meta\ninclude/net/libeth/xsk.h-217- * @xdesc: \u0026xdp_desc from the XSk buffer pool\n--\ninclude/net/libeth/xsk.h=223=static inline struct libeth_xdp_tx_desc\ninclude/net/libeth/xsk.h:224:__libeth_xsk_xmit_fill_buf(const struct xdp_desc *xdesc,\ninclude/net/libeth/xsk.h-225-\t\t\t   const struct libeth_xdpsq *sq)\n--\ninclude/net/libeth/xsk.h-233-/**\ninclude/net/libeth/xsk.h:234: * libeth_xsk_xmit_fill_buf - internal helper to prepare an XSk xmit\ninclude/net/libeth/xsk.h-235- * @frm: \u0026xdp_desc from the XSk buffer pool\n--\ninclude/net/libeth/xsk.h=246=static __always_inline struct libeth_xdp_tx_desc\ninclude/net/libeth/xsk.h:247:libeth_xsk_xmit_fill_buf(struct libeth_xdp_tx_frame frm, u32 i,\ninclude/net/libeth/xsk.h-248-\t\t\t const struct libeth_xdpsq *sq, u64 priv)\n--\ninclude/net/libeth/xsk.h-252-\tif (priv)\ninclude/net/libeth/xsk.h:253:\t\tdesc = __libeth_xsk_xmit_fill_buf_md(\u0026frm.desc, sq, priv);\ninclude/net/libeth/xsk.h-254-\telse\ninclude/net/libeth/xsk.h:255:\t\tdesc = __libeth_xsk_xmit_fill_buf(\u0026frm.desc, sq);\ninclude/net/libeth/xsk.h-256-\n--\ninclude/net/libeth/xsk.h=285=libeth_xsk_xmit_do_bulk(struct xsk_buff_pool *pool, void *xdpsq, u32 budget,\n--\ninclude/net/libeth/xsk.h-304-\t\t\t\tlibeth_xdp_ptr_to_priv(tmo), prep,\ninclude/net/libeth/xsk.h:305:\t\t\t\tlibeth_xsk_xmit_fill_buf, xmit);\ninclude/net/libeth/xsk.h-306-\tfinalize(xdpsq, n, true);\n"
}
13/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 11540
							output: 26
							thoughts: 18

Thoughts: 
Here's a summary of my understanding, framed from my perspective as an expert:

**Understanding libeth_xsk_xmit_do_bulk**

Okay, so I'm thinking about `libeth_xsk_xmit_do_bulk`. The immediate question is always, where exactly is this function being utilized in my network stack or application? It's that direct, practical application that matters. Am I dealing with a specific XDP implementation, maybe something custom-built around AF_XDP sockets? Or is it part of a broader networking library, used as a low-level primitive for packet transmission?

I'm mentally mapping the code flow. I need to refresh my memory on the surrounding functions. What does the bulk transmission imply? Is it a way to optimize throughput by batching packets, similar to how other interfaces work, but specific for XDP? Is it managing the complexities of ring buffer interaction and hardware offload? I need to check the data structures involved, the parameters passed, and how the packets are prepared for transmission. What are the performance implications? Is it efficient, or are there bottlenecks I need to be aware of?

Let's drill down into the specific implementation, I need to know where I can find the function used in our systems.

14/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "libeth_xsk_xmit_do_bulk"
}

Results: 
{
  "Output": "drivers/net/ethernet/intel/idpf/xsk.c=316=bool idpf_xsk_xmit(struct idpf_tx_queue *xsksq)\n--\ndrivers/net/ethernet/intel/idpf/xsk.c-325-\ndrivers/net/ethernet/intel/idpf/xsk.c:326:\treturn libeth_xsk_xmit_do_bulk(xsksq-\u003epool, xsksq,\ndrivers/net/ethernet/intel/idpf/xsk.c-327-\t\t\t\t       min(free - 1, xsksq-\u003ethresh),\n--\ninclude/net/libeth/xsk.h=247=libeth_xsk_xmit_fill_buf(struct libeth_xdp_tx_frame frm, u32 i,\n--\ninclude/net/libeth/xsk.h-264-/**\ninclude/net/libeth/xsk.h:265: * libeth_xsk_xmit_do_bulk - send XSk xmit frames\ninclude/net/libeth/xsk.h-266- * @pool: XSk buffer pool containing the frames to send\n--\ninclude/net/libeth/xsk.h=284=static __always_inline bool\ninclude/net/libeth/xsk.h:285:libeth_xsk_xmit_do_bulk(struct xsk_buff_pool *pool, void *xdpsq, u32 budget,\ninclude/net/libeth/xsk.h-286-\t\t\tconst struct xsk_tx_metadata_ops *tmo,\n"
}
15/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 12259
							output: 36
							thoughts: 85

Thoughts: 
Okay, let me think this through.

**Investigating XSK Transmission Paths in Virtual Drivers**

Alright, so I'm focusing on how `libeth_xsk_xmit_do_bulk` factors into the picture. I see that it's being called within `idpf_xsk_xmit`, which I know is part of the Intel Infrastructure Data Path Function driver, so a hardware-level component. Now, my question is, are any of the *virtual* drivers out there, you know, the ones that often abstract away the hardware, utilizing either `xsk_buff_get_metadata` or `xp_raw_get_ctx` in their implementations? I'm specifically wondering if they're interacting with the XDP Socket layer at all, or perhaps I'm looking at this in the wrong manner. My first hunch? Let's take a look at `veth`. It's a common and well-understood virtual Ethernet pair, and a sensible place to start my investigation. Perhaps the answer lies there.

16/2 2026/08/10 22:38 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_get_metadata",
  "PathPrefix": "drivers/net/veth.c"
}

Results: 
{
  "error": "no matches"
}
17/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 12614
							output: 35
							thoughts: 18

Thoughts: 
Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person:

**Diving into `xp_raw_get_ctx` within the `veth` Context**

Alright, time to get down to brass tacks. My initial thought process is to zero in on `xp_raw_get_ctx`, specifically within the `veth` context. This likely indicates I'm troubleshooting, debugging, or perhaps optimizing something related to how raw packets are handled when `veth` interfaces are involved. I'm immediately interested in the implementation details of that function. Is it working as expected? Are there any potential bottlenecks there? What data structures does it interact with? I need to understand how context is retrieved, what that context represents, and how it is subsequently used. My concern is perhaps in the relationship between this and the other features implemented.

18/2 2026/08/10 22:38 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xp_raw_get_ctx",
  "PathPrefix": "drivers/net/veth.c"
}

Results: 
{
  "error": "no matches"
}
19/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 12866
							output: 22
							thoughts: 18

Thoughts: 
Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Investigating Related XDP Metadata Requests**

Alright, so the initial thought is a little vague. We've got a problem, and the direction isn't entirely clear. To get my bearings, let's zero in on a specific, potentially related function: `xsk_tx_metadata_request`. I'm immediately thinking this could hold the key. Metadata, particularly within the context of XDP, often provides crucial context or additional information about a packet or request. I'm going to start by diving into the details of that call – it's likely where the root of the issue is exposed. This function's probably key, so let's check it out!

20/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "xsk_tx_metadata_request"
}

Results: 
{
  "Output": "drivers/net/ethernet/intel/igc/igc_main.c=3034=static void igc_xdp_xmit_zc(struct igc_ring *ring)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-3082-\t\tmeta_req.used_desc = 0;\ndrivers/net/ethernet/intel/igc/igc_main.c:3083:\t\txsk_tx_metadata_request(pool, \u0026meta, \u0026igc_xsk_tx_metadata_ops,\ndrivers/net/ethernet/intel/igc/igc_main.c-3084-\t\t\t\t\t\u0026meta_req);\ndrivers/net/ethernet/intel/igc/igc_main.c-3085-\ndrivers/net/ethernet/intel/igc/igc_main.c:3086:\t\t/* xsk_tx_metadata_request() may have updated next_to_use */\ndrivers/net/ethernet/intel/igc/igc_main.c-3087-\t\tntu = ring-\u003enext_to_use;\ndrivers/net/ethernet/intel/igc/igc_main.c-3088-\ndrivers/net/ethernet/intel/igc/igc_main.c:3089:\t\t/* xsk_tx_metadata_request() may have updated Tx buffer info */\ndrivers/net/ethernet/intel/igc/igc_main.c-3090-\t\tbi = meta_req.tx_buffer;\ndrivers/net/ethernet/intel/igc/igc_main.c-3091-\ndrivers/net/ethernet/intel/igc/igc_main.c:3092:\t\t/* xsk_tx_metadata_request() may use a few descriptors */\ndrivers/net/ethernet/intel/igc/igc_main.c-3093-\t\tbudget -= meta_req.used_desc;\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=458=mlx5e_xmit_xdp_frame_mpwqe(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-507-\t\tif (meta)\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:508:\t\t\txsk_tx_metadata_request(sq-\u003exsk_pool, meta,\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-509-\t\t\t\t\t\t\u0026mlx5e_xsk_tx_metadata_ops,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=540=mlx5e_xmit_xdp_frame(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-655-\tif (meta)\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:656:\t\txsk_tx_metadata_request(sq-\u003exsk_pool, meta,\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-657-\t\t\t\t\t\u0026mlx5e_xsk_tx_metadata_ops, eseg);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=2681=static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2748-\t\tmeta_req.edesc = \u0026tx_q-\u003edma_entx[entry];\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2749:\t\txsk_tx_metadata_request(pool, \u0026meta,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2750-\t\t\t\t\t\u0026stmmac_xsk_tx_metadata_ops, \u0026meta_req);\n--\ninclude/net/libeth/xsk.h=191=__libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\n--\ninclude/net/libeth/xsk.h-207-\ninclude/net/libeth/xsk.h:208:\txsk_tx_metadata_request(sq-\u003epool, \u0026ctx.meta, tmo, \u0026desc);\ninclude/net/libeth/xsk.h-209-\n--\ninclude/net/xdp_sock.h=141=static inline void xsk_tx_metadata_to_compl(struct xsk_tx_metadata *meta,\n--\ninclude/net/xdp_sock.h-149-\t/* we can only arrive here if the completion timestamp has been\ninclude/net/xdp_sock.h:150:\t * requested via XDP_TXMD_FLAGS_TIMESTAMP, see xsk_tx_metadata_request\ninclude/net/xdp_sock.h-151-\t */\n--\ninclude/net/xdp_sock_drv.h=264=xsk_buff_valid_tx_metadata(const struct xsk_buff_pool *pool,\n--\ninclude/net/xdp_sock_drv.h-275-/**\ninclude/net/xdp_sock_drv.h:276: *  xsk_tx_metadata_request - Evaluate AF_XDP TX metadata at submission\ninclude/net/xdp_sock_drv.h-277- *  and call appropriate xsk_tx_metadata_ops operation.\n--\ninclude/net/xdp_sock_drv.h=286=static inline void\ninclude/net/xdp_sock_drv.h:287:xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\ninclude/net/xdp_sock_drv.h-288-\t\t\tstruct xsk_tx_metadata **pmeta,\n--\ninclude/net/xdp_sock_drv.h=528=static inline void\ninclude/net/xdp_sock_drv.h:529:xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\ninclude/net/xdp_sock_drv.h-530-\t\t\tstruct xsk_tx_metadata **pmeta,\n--\nnet/xdp/xsk_buff_pool.c=760=EXPORT_SYMBOL(xp_raw_get_dma);\n--\nnet/xdp/xsk_buff_pool.c-769- * Saves one call on hotpath and double calculation of the actual address.\nnet/xdp/xsk_buff_pool.c:770: * Metadata is validated later by xsk_tx_metadata_request().\nnet/xdp/xsk_buff_pool.c-771- *\n"
}
21/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 14863
							output: 22
							thoughts: 127

Thoughts: 
**Investigating AF_XDP Zero-Copy Support in `veth`**

Okay, so I'm looking at how AF_XDP zero-copy is handled in the kernel, and the `xsk_tx_metadata_request` is showing up in `igc`, `mlx5`, `stmmac`, and the `libeth_xsk_xmit_fill_buf_md` code. That's a good starting point, showing a few different drivers that are taking advantage of this metadata request. However, I've got a nagging suspicion about `veth`.

Now, I remember seeing that `veth` uses `veth_xdp_xmit`, which in turn calls `veth_xdp_xmit_one`. And from a quick glance, it doesn't immediately seem like `veth_xdp_xmit_one` is leveraging `xsk_tx_metadata_request`. This raises a red flag. Does `veth` have support for AF_XDP zero-copy, or am I missing something? It seems unlikely.

I'm thinking I need to verify that `veth` actually has `xsk_tx_metadata_ops` defined. Let's dig in and check. That's the key.

22/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "xsk_tx_metadata_ops"
}

Results: 
{
  "Output": "drivers/net/ethernet/intel/idpf/xdp.h=22=bool idpf_xdp_tx_flush_bulk(struct libeth_xdp_tx_bulk *bq, u32 flags);\n--\ndrivers/net/ethernet/intel/idpf/xdp.h-28- * @sq: XDP queue to produce the HW Tx descriptor on\ndrivers/net/ethernet/intel/idpf/xdp.h:29: * @priv: \u0026xsk_tx_metadata_ops on XSk xmit or %NULL\ndrivers/net/ethernet/intel/idpf/xdp.h-30- */\n--\ndrivers/net/ethernet/intel/igc/igc.h=375=int igc_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags);\n--\ndrivers/net/ethernet/intel/igc/igc.h-377-/* AF_XDP TX metadata operations */\ndrivers/net/ethernet/intel/igc/igc.h:378:extern const struct xsk_tx_metadata_ops igc_xsk_tx_metadata_ops;\ndrivers/net/ethernet/intel/igc/igc.h-379-\n--\ndrivers/net/ethernet/intel/igc/igc_main.c=2990=static void igc_xsk_request_launch_time(u64 launch_time, void *_priv)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-3027-\ndrivers/net/ethernet/intel/igc/igc_main.c:3028:const struct xsk_tx_metadata_ops igc_xsk_tx_metadata_ops = {\ndrivers/net/ethernet/intel/igc/igc_main.c-3029-\t.tmo_request_timestamp\t\t= igc_xsk_request_timestamp,\n--\ndrivers/net/ethernet/intel/igc/igc_main.c=3034=static void igc_xdp_xmit_zc(struct igc_ring *ring)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-3082-\t\tmeta_req.used_desc = 0;\ndrivers/net/ethernet/intel/igc/igc_main.c:3083:\t\txsk_tx_metadata_request(pool, \u0026meta, \u0026igc_xsk_tx_metadata_ops,\ndrivers/net/ethernet/intel/igc/igc_main.c-3084-\t\t\t\t\t\u0026meta_req);\n--\ndrivers/net/ethernet/intel/igc/igc_main.c=7120=static int igc_probe(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-7193-\tnetdev-\u003exdp_metadata_ops = \u0026igc_xdp_metadata_ops;\ndrivers/net/ethernet/intel/igc/igc_main.c:7194:\tnetdev-\u003exsk_tx_metadata_ops = \u0026igc_xsk_tx_metadata_ops;\ndrivers/net/ethernet/intel/igc/igc_main.c-7195-\tigc_ethtool_set_ops(netdev);\n--\ndrivers/net/ethernet/intel/igc/igc_ptp.c=749=static void igc_ptp_tx_reg_to_stamp(struct igc_adapter *adapter,\n--\ndrivers/net/ethernet/intel/igc/igc_ptp.c-787-\t\t\txsk_tx_metadata_complete(\u0026tstamp-\u003exsk_meta,\ndrivers/net/ethernet/intel/igc/igc_ptp.c:788:\t\t\t\t\t\t \u0026igc_xsk_tx_metadata_ops,\ndrivers/net/ethernet/intel/igc/igc_ptp.c-789-\t\t\t\t\t\t \u0026shhwtstamps.hwtstamp);\n--\ndrivers/net/ethernet/intel/libeth/priv.h=15=struct xdp_frame_bulk;\ndrivers/net/ethernet/intel/libeth/priv.h-16-\ndrivers/net/ethernet/intel/libeth/priv.h:17:extern const struct xsk_tx_metadata_ops libeth_xsktmo_slow;\ndrivers/net/ethernet/intel/libeth/priv.h-18-\n--\ndrivers/net/ethernet/intel/libeth/xdp.c=390=void __libeth_xdp_set_features(struct net_device *dev,\n--\ndrivers/net/ethernet/intel/libeth/xdp.c-392-\t\t\t       u32 zc_segs,\ndrivers/net/ethernet/intel/libeth/xdp.c:393:\t\t\t       const struct xsk_tx_metadata_ops *tmo)\ndrivers/net/ethernet/intel/libeth/xdp.c-394-{\n--\ndrivers/net/ethernet/intel/libeth/xdp.c-406-\tdev-\u003exdp_zc_max_segs = zc_segs ? : 1;\ndrivers/net/ethernet/intel/libeth/xdp.c:407:\tdev-\u003exsk_tx_metadata_ops = zc_segs ? tmo : NULL;\ndrivers/net/ethernet/intel/libeth/xdp.c-408-}\n--\ndrivers/net/ethernet/intel/libeth/xsk.c=14=void __cold libeth_xsk_tx_return_bulk(const struct libeth_xdp_tx_frame *bq,\n--\ndrivers/net/ethernet/intel/libeth/xsk.c-22-\ndrivers/net/ethernet/intel/libeth/xsk.c:23:const struct xsk_tx_metadata_ops libeth_xsktmo_slow = {\ndrivers/net/ethernet/intel/libeth/xsk.c-24-\t.tmo_request_checksum\t\t= libeth_xsktmo_req_csum,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=304=static void mlx5e_xsk_request_checksum(u16 csum_start, u16 csum_offset, void *priv)\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-311-\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:312:const struct xsk_tx_metadata_ops mlx5e_xsk_tx_metadata_ops = {\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-313-\t.tmo_fill_timestamp\t\t= mlx5e_xsk_fill_timestamp,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=458=mlx5e_xmit_xdp_frame_mpwqe(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-508-\t\t\txsk_tx_metadata_request(sq-\u003exsk_pool, meta,\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:509:\t\t\t\t\t\t\u0026mlx5e_xsk_tx_metadata_ops,\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-510-\t\t\t\t\t\t\u0026session-\u003ewqe-\u003eeth);\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=540=mlx5e_xmit_xdp_frame(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-656-\t\txsk_tx_metadata_request(sq-\u003exsk_pool, meta,\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:657:\t\t\t\t\t\u0026mlx5e_xsk_tx_metadata_ops, eseg);\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-658-\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c=665=static void mlx5e_free_xdpsq_desc(struct mlx5e_xdpsq *sq,\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-742-\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:743:\t\t\t\txsk_tx_metadata_complete(compl, \u0026mlx5e_xsk_tx_metadata_ops, \u0026priv);\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.c-744-\t\t\t}\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.h=111=extern const struct xdp_metadata_ops mlx5e_xdp_metadata_ops;\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.h:112:extern const struct xsk_tx_metadata_ops mlx5e_xsk_tx_metadata_ops;\ndrivers/net/ethernet/mellanox/mlx5/core/en/xdp.h-113-\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_main.c=5829=static void mlx5e_build_nic_netdev(struct net_device *netdev)\n--\ndrivers/net/ethernet/mellanox/mlx5/core/en_main.c-5840-\tnetdev-\u003exdp_metadata_ops = \u0026mlx5e_xdp_metadata_ops;\ndrivers/net/ethernet/mellanox/mlx5/core/en_main.c:5841:\tnetdev-\u003exsk_tx_metadata_ops = \u0026mlx5e_xsk_tx_metadata_ops;\ndrivers/net/ethernet/mellanox/mlx5/core/en_main.c-5842-\tnetdev-\u003erequest_ops_lock = true;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=2665=static void stmmac_xsk_request_launch_time(u64 launch_time, void *_priv)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2674-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2675:static const struct xsk_tx_metadata_ops stmmac_xsk_tx_metadata_ops = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2676-\t.tmo_request_timestamp\t\t= stmmac_xsk_request_timestamp,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=2681=static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2749-\t\txsk_tx_metadata_request(pool, \u0026meta,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2750:\t\t\t\t\t\u0026stmmac_xsk_tx_metadata_ops, \u0026meta_req);\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2751-\t\tif (set_ic) {\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=2811=static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2877-\t\t\t\txsk_tx_metadata_complete(\u0026tx_q-\u003etx_skbuff_dma[entry].xsk_meta,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2878:\t\t\t\t\t\t\t \u0026stmmac_xsk_tx_metadata_ops,\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-2879-\t\t\t\t\t\t\t \u0026tx_compl);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c=7784=static int __stmmac_dvr_probe(struct device *device,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7901-\tndev-\u003exdp_metadata_ops = \u0026stmmac_xdp_metadata_ops;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c:7902:\tndev-\u003exsk_tx_metadata_ops = \u0026stmmac_xsk_tx_metadata_ops;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_main.c-7903-\n--\ninclude/linux/netdevice.h=1812=enum netdev_reg_state {\n--\ninclude/linux/netdevice.h-1891- *\t@xdp_metadata_ops:\tIncludes pointers to XDP metadata callbacks.\ninclude/linux/netdevice.h:1892: *\t@xsk_tx_metadata_ops:\tIncludes pointers to AF_XDP TX metadata callbacks.\ninclude/linux/netdevice.h-1893- *\t@ethtool_ops:\tManagement operations\n--\ninclude/linux/netdevice.h=2152=struct net_device {\n--\ninclude/linux/netdevice.h-2262-\tconst struct xdp_metadata_ops *xdp_metadata_ops;\ninclude/linux/netdevice.h:2263:\tconst struct xsk_tx_metadata_ops *xsk_tx_metadata_ops;\ninclude/linux/netdevice.h-2264-\tunsigned short\t\tgflags;\n--\ninclude/net/libeth/xdp.h=1821=void __libeth_xdp_set_features(struct net_device *dev,\n--\ninclude/net/libeth/xdp.h-1823-\t\t\t       u32 zc_segs,\ninclude/net/libeth/xdp.h:1824:\t\t\t       const struct xsk_tx_metadata_ops *tmo);\ninclude/net/libeth/xdp.h-1825-void libeth_xdp_set_redirect(struct net_device *dev, bool enable);\n--\ninclude/net/libeth/xsk.h=167=static inline void libeth_xsktmo_req_csum(u16 csum_start, u16 csum_offset,\n--\ninclude/net/libeth/xsk.h-173-/* Only to inline the callbacks below, use @libeth_xsktmo in drivers instead */\ninclude/net/libeth/xsk.h:174:static const struct xsk_tx_metadata_ops __libeth_xsktmo = {\ninclude/net/libeth/xsk.h-175-\t.tmo_request_checksum\t= libeth_xsktmo_req_csum,\n--\ninclude/net/libeth/xsk.h=191=__libeth_xsk_xmit_fill_buf_md(const struct xdp_desc *xdesc,\n--\ninclude/net/libeth/xsk.h-194-{\ninclude/net/libeth/xsk.h:195:\tconst struct xsk_tx_metadata_ops *tmo = libeth_xdp_priv_to_ptr(priv);\ninclude/net/libeth/xsk.h-196-\tstruct libeth_xdp_tx_desc desc;\n--\ninclude/net/libeth/xsk.h=285=libeth_xsk_xmit_do_bulk(struct xsk_buff_pool *pool, void *xdpsq, u32 budget,\ninclude/net/libeth/xsk.h:286:\t\t\tconst struct xsk_tx_metadata_ops *tmo,\ninclude/net/libeth/xsk.h-287-\t\t\tu32 (*prep)(void *xdpsq, struct libeth_xdpsq *sq),\n--\ninclude/net/xdp_sock.h=48=struct xdp_sock {\n--\ninclude/net/xdp_sock.h-116- */\ninclude/net/xdp_sock.h:117:struct xsk_tx_metadata_ops {\ninclude/net/xdp_sock.h-118-\tvoid\t(*tmo_request_timestamp)(void *priv);\n--\ninclude/net/xdp_sock.h=141=static inline void xsk_tx_metadata_to_compl(struct xsk_tx_metadata *meta,\n--\ninclude/net/xdp_sock.h-157- *  xsk_tx_metadata_complete - Evaluate AF_XDP TX metadata at completion\ninclude/net/xdp_sock.h:158: *  and call appropriate xsk_tx_metadata_ops operation.\ninclude/net/xdp_sock.h-159- *  @compl: pointer to completion metadata produced from xsk_tx_metadata_to_compl\ninclude/net/xdp_sock.h:160: *  @ops: pointer to struct xsk_tx_metadata_ops\ninclude/net/xdp_sock.h-161- *  @priv: pointer to driver-private aread\n--\ninclude/net/xdp_sock.h=166=static inline void xsk_tx_metadata_complete(struct xsk_tx_metadata_compl *compl,\ninclude/net/xdp_sock.h:167:\t\t\t\t\t    const struct xsk_tx_metadata_ops *ops,\ninclude/net/xdp_sock.h-168-\t\t\t\t\t    void *priv)\n--\ninclude/net/xdp_sock.h=205=static inline void xsk_tx_metadata_complete(struct xsk_tx_metadata_compl *compl,\ninclude/net/xdp_sock.h:206:\t\t\t\t\t    const struct xsk_tx_metadata_ops *ops,\ninclude/net/xdp_sock.h-207-\t\t\t\t\t    void *priv)\n--\ninclude/net/xdp_sock_drv.h=264=xsk_buff_valid_tx_metadata(const struct xsk_buff_pool *pool,\n--\ninclude/net/xdp_sock_drv.h-276- *  xsk_tx_metadata_request - Evaluate AF_XDP TX metadata at submission\ninclude/net/xdp_sock_drv.h:277: *  and call appropriate xsk_tx_metadata_ops operation.\ninclude/net/xdp_sock_drv.h-278- *  @pool: pointer to AF_XDP buffer pool, used to validate the metadata\ninclude/net/xdp_sock_drv.h-279- *  @pmeta: pointer to pointer to AF_XDP metadata area\ninclude/net/xdp_sock_drv.h:280: *  @ops: pointer to struct xsk_tx_metadata_ops\ninclude/net/xdp_sock_drv.h-281- *  @priv: pointer to driver-private area\n--\ninclude/net/xdp_sock_drv.h=287=xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\ninclude/net/xdp_sock_drv.h-288-\t\t\tstruct xsk_tx_metadata **pmeta,\ninclude/net/xdp_sock_drv.h:289:\t\t\tconst struct xsk_tx_metadata_ops *ops, void *priv)\ninclude/net/xdp_sock_drv.h-290-{\n--\ninclude/net/xdp_sock_drv.h=529=xsk_tx_metadata_request(const struct xsk_buff_pool *pool,\ninclude/net/xdp_sock_drv.h-530-\t\t\tstruct xsk_tx_metadata **pmeta,\ninclude/net/xdp_sock_drv.h:531:\t\t\tconst struct xsk_tx_metadata_ops *ops, void *priv)\ninclude/net/xdp_sock_drv.h-532-{\n--\nnet/core/netdev-genl.c=51=XDP_METADATA_KFUNC_xxx\n--\nnet/core/netdev-genl.c-53-\nnet/core/netdev-genl.c:54:\tif (netdev-\u003exsk_tx_metadata_ops) {\nnet/core/netdev-genl.c:55:\t\tif (netdev-\u003exsk_tx_metadata_ops-\u003etmo_fill_timestamp)\nnet/core/netdev-genl.c-56-\t\t\txsk_features |= NETDEV_XSK_FLAGS_TX_TIMESTAMP;\nnet/core/netdev-genl.c:57:\t\tif (netdev-\u003exsk_tx_metadata_ops-\u003etmo_request_checksum)\nnet/core/netdev-genl.c-58-\t\t\txsk_features |= NETDEV_XSK_FLAGS_TX_CHECKSUM;\nnet/core/netdev-genl.c:59:\t\tif (netdev-\u003exsk_tx_metadata_ops-\u003etmo_request_launch_time)\nnet/core/netdev-genl.c-60-\t\t\txsk_features |= NETDEV_XSK_FLAGS_TX_LAUNCH_TIME_FIFO;\n"
}
23/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 20786
							output: 34
							thoughts: 204

Thoughts: 
**Investigating AF_XDP TX Metadata Operations**

Okay, so I'm digging into `xsk_tx_metadata_ops` and it looks like it's only implemented in a few drivers: `igc`, `mlx5`, `stmmac`, and `idpf`. That seems a little limited. Now, wait a minute... I don't recall seeing it in `veth`. Hmm, `veth` is a virtual interface, so how does it handle metadata in the TX path? Does it rely on `xsk_buff_get_metadata` or perhaps `xp_raw_get_ctx` instead?

Let me double-check `veth` just to be sure. I *thought* I grepped for both functions, `xp_raw_get_ctx` and `xsk_buff_get_metadata`, within `drivers/net/veth.c`, but no dice. I'll extend the search, just in case, and expand it to the `net/xdp/` and `net/core/` directories, looking for `xp_raw_get_ctx`. Is there some clever virtual driver, perhaps one supporting AF_XDP zero copy, that might be using these functions in a non-obvious way?

Okay, since it's a virtual interface, perhaps I should also check for `xsk_buff_pool` within `drivers/net/veth.c`, to see how it's managing buffer pools. This line of inquiry should tell the tale of how it does things.

24/2 2026/08/10 22:38 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_pool",
  "PathPrefix": "drivers/net/veth.c"
}

Results: 
{
  "error": "no matches"
}
25/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 21369
							output: 30
							thoughts: 47

Thoughts: 
**Investigating AF_XDP and Zero-Copy Support**

Okay, hold on a second... I was under the impression that the `veth` interface utilized the `xsk_buff_pool` for AF_XDP zero-copy operations, but now I'm doubting that assumption. I need to clarify that. My understanding is that AF_XDP's zero-copy functionality isn't universally supported across all network drivers; it's specific to certain hardware and, therefore, the corresponding kernel drivers. So, I need to pinpoint which drivers actually *do* support AF_XDP's zero-copy. Let's get a list and verify the compatibility matrix. I need to be sure before I implement anything. This is a critical detail.

26/2 2026/08/10 22:38 tool grepper
0m Args: 
{
  "Expression": "xsk_buff_pool",
  "PathPrefix": "drivers/net/"
}

Results: 
{
  "Output": "\nFull output is too long, showing 500 out of 918 lines.\nUse more precise expression if possible.\n\ndrivers/net/ethernet/engleder/tsnep.h=80=struct tsnep_tx {\n--\ndrivers/net/ethernet/engleder/tsnep.h-92-\tint increment_owner_counter;\ndrivers/net/ethernet/engleder/tsnep.h:93:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/engleder/tsnep.h-94-\n--\ndrivers/net/ethernet/engleder/tsnep.h=115=struct tsnep_rx {\n--\ndrivers/net/ethernet/engleder/tsnep.h-130-\tstruct page **page_buffer;\ndrivers/net/ethernet/engleder/tsnep.h:131:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/engleder/tsnep.h-132-\tstruct xdp_buff **xdp_batch;\n--\ndrivers/net/ethernet/engleder/tsnep.h=231=int tsnep_xdp_setup_pool(struct tsnep_adapter *adapter,\ndrivers/net/ethernet/engleder/tsnep.h:232:\t\t\t struct xsk_buff_pool *pool, u16 queue_id);\ndrivers/net/ethernet/engleder/tsnep.h-233-\n--\ndrivers/net/ethernet/engleder/tsnep.h=260=u32 tsnep_get_irq_coalesce(struct tsnep_queue *queue);\ndrivers/net/ethernet/engleder/tsnep.h:261:int tsnep_enable_xsk(struct tsnep_queue *queue, struct xsk_buff_pool *pool);\ndrivers/net/ethernet/engleder/tsnep.h-262-void tsnep_disable_xsk(struct tsnep_queue *queue);\n--\ndrivers/net/ethernet/engleder/tsnep_main.c=2074=static int tsnep_netdev_close(struct net_device *netdev)\n--\ndrivers/net/ethernet/engleder/tsnep_main.c-2095-\ndrivers/net/ethernet/engleder/tsnep_main.c:2096:int tsnep_enable_xsk(struct tsnep_queue *queue, struct xsk_buff_pool *pool)\ndrivers/net/ethernet/engleder/tsnep_main.c-2097-{\n--\ndrivers/net/ethernet/engleder/tsnep_xdp.c=21=static int tsnep_xdp_enable_pool(struct tsnep_adapter *adapter,\ndrivers/net/ethernet/engleder/tsnep_xdp.c:22:\t\t\t\t struct xsk_buff_pool *pool, u16 queue_id)\ndrivers/net/ethernet/engleder/tsnep_xdp.c-23-{\n--\ndrivers/net/ethernet/engleder/tsnep_xdp.c=58=static int tsnep_xdp_disable_pool(struct tsnep_adapter *adapter, u16 queue_id)\ndrivers/net/ethernet/engleder/tsnep_xdp.c-59-{\ndrivers/net/ethernet/engleder/tsnep_xdp.c:60:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/engleder/tsnep_xdp.c-61-\tstruct tsnep_queue *queue;\n--\ndrivers/net/ethernet/engleder/tsnep_xdp.c=80=int tsnep_xdp_setup_pool(struct tsnep_adapter *adapter,\ndrivers/net/ethernet/engleder/tsnep_xdp.c:81:\t\t\t struct xsk_buff_pool *pool, u16 queue_id)\ndrivers/net/ethernet/engleder/tsnep_xdp.c-82-{\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h=486=struct dpaa2_eth_channel {\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h-506-\tint xsk_tx_pkts_sent;\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h:507:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h-508-\tstruct dpaa2_eth_bp *bp;\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h=846=int dpaa2_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags);\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h:847:int dpaa2_xsk_setup_pool(struct net_device *dev, struct xsk_buff_pool *pool, u16 qid);\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h-848-\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c=173=static int dpaa2_xsk_disable_pool(struct net_device *dev, u16 qid)\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c-174-{\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c:175:\tstruct xsk_buff_pool *pool = xsk_get_pool_from_qid(dev, qid);\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c-176-\tstruct dpaa2_eth_priv *priv = netdev_priv(dev);\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c=220=static int dpaa2_xsk_enable_pool(struct net_device *dev,\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c:221:\t\t\t\t struct xsk_buff_pool *pool,\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c-222-\t\t\t\t u16 qid)\n--\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c-302-\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c:303:int dpaa2_xsk_setup_pool(struct net_device *dev, struct xsk_buff_pool *pool, u16 qid)\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-xsk.c-304-{\n--\ndrivers/net/ethernet/freescale/fec.h=541=struct fec_enet_priv_tx_q {\n--\ndrivers/net/ethernet/freescale/fec.h-544-\tstruct fec_tx_buffer tx_buf[TX_RING_SIZE];\ndrivers/net/ethernet/freescale/fec.h:545:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/freescale/fec.h-546-\n--\ndrivers/net/ethernet/freescale/fec.h=561=struct fec_enet_priv_rx_q {\n--\ndrivers/net/ethernet/freescale/fec.h-563-\tunion fec_rx_buffer rx_buf[RX_RING_SIZE];\ndrivers/net/ethernet/freescale/fec.h:564:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/freescale/fec.h-565-\n--\ndrivers/net/ethernet/freescale/fec_main.c=1482=static bool fec_enet_xsk_xmit(struct fec_enet_private *fep,\ndrivers/net/ethernet/freescale/fec_main.c:1483:\t\t\t      struct xsk_buff_pool *pool,\ndrivers/net/ethernet/freescale/fec_main.c-1484-\t\t\t      u32 queue)\n--\ndrivers/net/ethernet/freescale/fec_main.c=1565=static int fec_enet_tx_queue(struct fec_enet_private *fep,\n--\ndrivers/net/ethernet/freescale/fec_main.c-1719-\tif (txq-\u003exsk_pool) {\ndrivers/net/ethernet/freescale/fec_main.c:1720:\t\tstruct xsk_buff_pool *pool = txq-\u003exsk_pool;\ndrivers/net/ethernet/freescale/fec_main.c-1721-\n--\ndrivers/net/ethernet/freescale/fec_main.c=4420=fec_alloc_new_rxq_xsk(struct fec_enet_private *fep, int queue,\ndrivers/net/ethernet/freescale/fec_main.c:4421:\t\t      struct xsk_buff_pool *pool)\ndrivers/net/ethernet/freescale/fec_main.c-4422-{\n--\ndrivers/net/ethernet/freescale/fec_main.c=4522=static int fec_xsk_restart_napi(struct fec_enet_private *fep,\ndrivers/net/ethernet/freescale/fec_main.c:4523:\t\t\t\tstruct xsk_buff_pool *pool,\ndrivers/net/ethernet/freescale/fec_main.c-4524-\t\t\t\tu16 queue)\n--\ndrivers/net/ethernet/freescale/fec_main.c=4561=static int fec_enable_xsk_pool(struct fec_enet_private *fep,\ndrivers/net/ethernet/freescale/fec_main.c:4562:\t\t\t       struct xsk_buff_pool *pool,\ndrivers/net/ethernet/freescale/fec_main.c-4563-\t\t\t       u16 queue)\n--\ndrivers/net/ethernet/freescale/fec_main.c=4592=static int fec_disable_xsk_pool(struct fec_enet_private *fep,\n--\ndrivers/net/ethernet/freescale/fec_main.c-4595-\tstruct fec_enet_priv_tx_q *txq = fep-\u003etx_queue[queue];\ndrivers/net/ethernet/freescale/fec_main.c:4596:\tstruct xsk_buff_pool *old_pool = txq-\u003exsk_pool;\ndrivers/net/ethernet/freescale/fec_main.c-4597-\tint err;\n--\ndrivers/net/ethernet/freescale/fec_main.c=4618=static int fec_setup_xsk_pool(struct fec_enet_private *fep,\ndrivers/net/ethernet/freescale/fec_main.c:4619:\t\t\t      struct xsk_buff_pool *pool,\ndrivers/net/ethernet/freescale/fec_main.c-4620-\t\t\t      u16 queue)\n--\ndrivers/net/ethernet/google/gve/gve.h=242=struct gve_rx_ring {\n--\ndrivers/net/ethernet/google/gve/gve.h-343-\tstruct xdp_rxq_info xdp_rxq;\ndrivers/net/ethernet/google/gve/gve.h:344:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/google/gve/gve.h-345-\tstruct page_frag_cache page_cache; /* Page cache to allocate XDP frames */\n--\ndrivers/net/ethernet/google/gve/gve.h=473=struct gve_tx_ring {\n--\ndrivers/net/ethernet/google/gve/gve.h-659-\tstruct u64_stats_sync statss; /* sync stats for 32bit archs */\ndrivers/net/ethernet/google/gve/gve.h:660:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/google/gve/gve.h-661-\tu64 xdp_xsk_sent;\n--\ndrivers/net/ethernet/google/gve/gve_main.c=1227=static int gve_reg_xsk_pool(struct gve_priv *priv, struct net_device *dev,\ndrivers/net/ethernet/google/gve/gve_main.c:1228:\t\t\t    struct xsk_buff_pool *pool, u16 qid)\ndrivers/net/ethernet/google/gve/gve_main.c-1229-{\n--\ndrivers/net/ethernet/google/gve/gve_main.c=1250=static void gve_unreg_xdp_info(struct gve_priv *priv)\n--\ndrivers/net/ethernet/google/gve/gve_main.c-1266-\ndrivers/net/ethernet/google/gve/gve_main.c:1267:static struct xsk_buff_pool *gve_get_xsk_pool(struct gve_priv *priv, int qid)\ndrivers/net/ethernet/google/gve/gve_main.c-1268-{\n--\ndrivers/net/ethernet/google/gve/gve_main.c=1275=static int gve_reg_xdp_info(struct gve_priv *priv, struct net_device *dev)\n--\ndrivers/net/ethernet/google/gve/gve_main.c-1285-\tfor (i = 0; i \u003c priv-\u003erx_cfg.num_queues; i++) {\ndrivers/net/ethernet/google/gve/gve_main.c:1286:\t\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/google/gve/gve_main.c-1287-\n--\ndrivers/net/ethernet/google/gve/gve_main.c=1629=static int gve_xsk_pool_enable(struct net_device *dev,\ndrivers/net/ethernet/google/gve/gve_main.c:1630:\t\t\t       struct xsk_buff_pool *pool,\ndrivers/net/ethernet/google/gve/gve_main.c-1631-\t\t\t       u16 qid)\n--\ndrivers/net/ethernet/google/gve/gve_main.c=1679=static int gve_xsk_pool_disable(struct net_device *dev,\n--\ndrivers/net/ethernet/google/gve/gve_main.c-1684-\tstruct napi_struct *napi_tx;\ndrivers/net/ethernet/google/gve/gve_main.c:1685:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/google/gve/gve_main.c-1686-\tint tx_qid;\n--\ndrivers/net/ethernet/google/gve/gve_tx_dqo.c=1084=static bool gve_xsk_tx_dqo(struct gve_priv *priv, struct gve_tx_ring *tx,\n--\ndrivers/net/ethernet/google/gve/gve_tx_dqo.c-1086-{\ndrivers/net/ethernet/google/gve/gve_tx_dqo.c:1087:\tstruct xsk_buff_pool *pool = tx-\u003exsk_pool;\ndrivers/net/ethernet/google/gve/gve_tx_dqo.c-1088-\tstruct xdp_desc desc;\n--\ndrivers/net/ethernet/intel/i40e/i40e_main.c=3402=static void i40e_config_xps_tx_ring(struct i40e_ring *ring)\n--\ndrivers/net/ethernet/intel/i40e/i40e_main.c-3423- **/\ndrivers/net/ethernet/intel/i40e/i40e_main.c:3424:static struct xsk_buff_pool *i40e_xsk_pool(struct i40e_ring *ring)\ndrivers/net/ethernet/intel/i40e/i40e_main.c-3425-{\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.h=327=struct i40e_ring {\n--\ndrivers/net/ethernet/intel/i40e/i40e_txrx.h-401-\tstruct xdp_rxq_info xdp_rxq;\ndrivers/net/ethernet/intel/i40e/i40e_txrx.h:402:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/i40e/i40e_txrx.h-403-} ____cacheline_internodealigned_in_smp;\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c=82=static int i40e_xsk_pool_enable(struct i40e_vsi *vsi,\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c:83:\t\t\t\tstruct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-84-\t\t\t\tu16 qid)\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c=138=static int i40e_xsk_pool_disable(struct i40e_vsi *vsi, u16 qid)\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-140-\tstruct net_device *netdev = vsi-\u003enetdev;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c:141:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-142-\tbool if_running;\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-182- **/\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c:183:int i40e_xsk_pool_setup(struct i40e_vsi *vsi, struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-184-\t\t\tu16 qid)\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c=630=bool i40e_clean_xdp_tx_irq(struct i40e_vsi *vsi, struct i40e_ring *tx_ring)\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-631-{\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c:632:\tstruct xsk_buff_pool *bp = tx_ring-\u003exsk_pool;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-633-\tu32 i, completed_frames, xsk_frames = 0;\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c=746=void i40e_xsk_clean_tx_ring(struct i40e_ring *tx_ring)\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-748-\tu16 ntc = tx_ring-\u003enext_to_clean, ntu = tx_ring-\u003enext_to_use;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c:749:\tstruct xsk_buff_pool *bp = tx_ring-\u003exsk_pool;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.c-750-\tstruct i40e_tx_buffer *tx_bi;\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h=19=struct net_device;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h:20:struct xsk_buff_pool;\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h-21-\n--\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h=23=int i40e_queue_pair_enable(struct i40e_vsi *vsi, int queue_pair);\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h:24:int i40e_xsk_pool_setup(struct i40e_vsi *vsi, struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/i40e/i40e_xsk.h-25-\t\t\tu16 qid);\n--\ndrivers/net/ethernet/intel/ice/ice.h=782=static inline bool ice_is_txtime_cfg(const struct ice_tx_ring *ring)\n--\ndrivers/net/ethernet/intel/ice/ice.h-791- *\ndrivers/net/ethernet/intel/ice/ice.h:792: * Return: A pointer to xsk_buff_pool structure if there is a buffer pool\ndrivers/net/ethernet/intel/ice/ice.h-793- * attached and configured as zero-copy, NULL otherwise.\ndrivers/net/ethernet/intel/ice/ice.h-794- */\ndrivers/net/ethernet/intel/ice/ice.h:795:static inline struct xsk_buff_pool *ice_get_xp_from_qid(struct ice_vsi *vsi,\ndrivers/net/ethernet/intel/ice/ice.h-796-\t\t\t\t\t\t\tu16 qid)\ndrivers/net/ethernet/intel/ice/ice.h-797-{\ndrivers/net/ethernet/intel/ice/ice.h:798:\tstruct xsk_buff_pool *pool = xsk_get_pool_from_qid(vsi-\u003enetdev, qid);\ndrivers/net/ethernet/intel/ice/ice.h-799-\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c=1267=int ice_napi_poll(struct napi_struct *napi, int budget)\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1280-\tice_for_each_tx_ring(tx_ring, q_vector-\u003etx) {\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1281:\t\tstruct xsk_buff_pool *xsk_pool = READ_ONCE(tx_ring-\u003exsk_pool);\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1282-\t\tbool wd;\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1310-\tice_for_each_rx_ring(rx_ring, q_vector-\u003erx) {\ndrivers/net/ethernet/intel/ice/ice_txrx.c:1311:\t\tstruct xsk_buff_pool *xsk_pool = READ_ONCE(rx_ring-\u003exsk_pool);\ndrivers/net/ethernet/intel/ice/ice_txrx.c-1312-\t\tint cleaned;\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.h=277=struct ice_rx_ring {\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.h-304-\tstruct ice_tx_ring *xdp_ring;\ndrivers/net/ethernet/intel/ice/ice_txrx.h:305:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/ice/ice_txrx.h-306-\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.h=349=struct ice_tx_ring {\n--\ndrivers/net/ethernet/intel/ice/ice_txrx.h-364-\ndrivers/net/ethernet/intel/ice/ice_txrx.h:365:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/ice/ice_txrx.h-366-\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=124=static int ice_xsk_pool_disable(struct ice_vsi *vsi, u16 qid)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-125-{\ndrivers/net/ethernet/intel/ice/ice_xsk.c:126:\tstruct xsk_buff_pool *pool = xsk_get_pool_from_qid(vsi-\u003enetdev, qid);\ndrivers/net/ethernet/intel/ice/ice_xsk.c-127-\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=144=static int\ndrivers/net/ethernet/intel/ice/ice_xsk.c:145:ice_xsk_pool_enable(struct ice_vsi *vsi, struct xsk_buff_pool *pool, u16 qid)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-146-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=174=ice_realloc_rx_xdp_bufs(struct ice_rx_ring *rx_ring, bool pool_present)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c-196- */\ndrivers/net/ethernet/intel/ice/ice_xsk.c:197:int ice_xsk_pool_setup(struct ice_vsi *vsi, struct xsk_buff_pool *pool, u16 qid)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-198-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c-259- */\ndrivers/net/ethernet/intel/ice/ice_xsk.c:260:static u16 ice_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-261-\t\t\t     union ice_32b_rx_flex_desc *rx_desc, u16 count)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=292=static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:293:\t\t\t\t   struct xsk_buff_pool *xsk_pool, u16 count)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-294-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=342=bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:343:\t\t\t  struct xsk_buff_pool *xsk_pool, u16 count)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-344-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=362=static u32 ice_clean_xdp_irq_zc(struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:363:\t\t\t\tstruct xsk_buff_pool *xsk_pool)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-364-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=432=static int ice_xmit_xdp_tx_zc(struct xdp_buff *xdp,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-433-\t\t\t      struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:434:\t\t\t      struct xsk_buff_pool *xsk_pool)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-435-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c-473-\t\ttx_desc-\u003ecmd_type_offset_bsz = ice_build_ctob(0, 0, size, 0);\ndrivers/net/ethernet/intel/ice/ice_xsk.c:474:\t\t/* account for each xdp_buff from xsk_buff_pool */\ndrivers/net/ethernet/intel/ice/ice_xsk.c-475-\t\txdp_ring-\u003exdp_tx_active++;\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=515=ice_run_xdp_zc(struct ice_rx_ring *rx_ring, struct xdp_buff *xdp,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-516-\t       struct bpf_prog *xdp_prog, struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:517:\t       struct xsk_buff_pool *xsk_pool)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-518-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=567=int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:568:\t\t\tstruct xsk_buff_pool *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-569-\t\t\tint budget)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=709=static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:710:\t\t\t struct xsk_buff_pool *xsk_pool, struct xdp_desc *desc,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-711-\t\t\t unsigned int *total_bytes)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=734=static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:735:\t\t\t       struct xsk_buff_pool *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-736-\t\t\t       struct xdp_desc *descs,\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c=769=static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.c:770:\t\t\t\tstruct xsk_buff_pool *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.c-771-\t\t\t\tstruct xdp_desc *descs, u32 nb_pkts,\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.c-790- */\ndrivers/net/ethernet/intel/ice/ice_xsk.c:791:bool ice_xmit_zc(struct ice_tx_ring *xdp_ring, struct xsk_buff_pool *xsk_pool)\ndrivers/net/ethernet/intel/ice/ice_xsk.c-792-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=10=struct ice_vsi;\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h-12-#ifdef CONFIG_XDP_SOCKETS\ndrivers/net/ethernet/intel/ice/ice_xsk.h:13:int ice_xsk_pool_setup(struct ice_vsi *vsi, struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.h-14-\t\t       u16 qid);\ndrivers/net/ethernet/intel/ice/ice_xsk.h=15=int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:16:\t\t\tstruct xsk_buff_pool *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.h-17-\t\t\tint budget);\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=19=bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:20:\t\t\t  struct xsk_buff_pool *xsk_pool, u16 count);\ndrivers/net/ethernet/intel/ice/ice_xsk.h-21-bool ice_xsk_any_rx_ring_ena(struct ice_vsi *vsi);\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=23=void ice_xsk_clean_xdp_ring(struct ice_tx_ring *xdp_ring);\ndrivers/net/ethernet/intel/ice/ice_xsk.h:24:bool ice_xmit_zc(struct ice_tx_ring *xdp_ring, struct xsk_buff_pool *xsk_pool);\ndrivers/net/ethernet/intel/ice/ice_xsk.h-25-int ice_realloc_rx_xdp_bufs(struct ice_rx_ring *rx_ring, bool pool_present);\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=34=static inline bool ice_xmit_zc(struct ice_tx_ring __always_unused *xdp_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:35:\t\t\t       struct xsk_buff_pool __always_unused *xsk_pool)\ndrivers/net/ethernet/intel/ice/ice_xsk.h-36-{\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=41=ice_xsk_pool_setup(struct ice_vsi __always_unused *vsi,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:42:\t\t   struct xsk_buff_pool __always_unused *pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.h-43-\t\t   u16 __always_unused qid)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=49=ice_clean_rx_irq_zc(struct ice_rx_ring __always_unused *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:50:\t\t    struct xsk_buff_pool __always_unused *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.h-51-\t\t    int __always_unused budget)\n--\ndrivers/net/ethernet/intel/ice/ice_xsk.h=57=ice_alloc_rx_bufs_zc(struct ice_rx_ring __always_unused *rx_ring,\ndrivers/net/ethernet/intel/ice/ice_xsk.h:58:\t\t     struct xsk_buff_pool __always_unused *xsk_pool,\ndrivers/net/ethernet/intel/ice/ice_xsk.h-59-\t\t     u16 __always_unused count)\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h=517=struct idpf_rx_queue {\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-563-\t\t\tstruct libeth_xdp_buff *xsk;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h:564:\t\t\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-565-\t\t};\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h=643=struct idpf_tx_queue {\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-659-\t\tstruct device *dev;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h:660:\t\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-661-\t};\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h=720=libeth_cacheline_set_assert(struct idpf_tx_queue, 64,\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-733- * @xsk_buf: \u0026xdp_buff for XSk Rx buffers\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h:734: * @pool: \u0026xsk_buff_pool on XSk queues\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-735- * @hdr_buf: \u0026libeth_fqe for header buffers\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h=755=struct idpf_buf_queue {\n--\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-764-\t\t\tstruct libeth_xdp_buff **xsk_buf;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h:765:\t\t\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/idpf_txrx.h-766-\t\t};\n--\ndrivers/net/ethernet/intel/idpf/xsk.c=12=static void idpf_xsk_setup_rxq(const struct idpf_vport *vport,\n--\ndrivers/net/ethernet/intel/idpf/xsk.c-14-{\ndrivers/net/ethernet/intel/idpf/xsk.c:15:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/xsk.c-16-\n--\ndrivers/net/ethernet/intel/idpf/xsk.c=26=static void idpf_xsk_setup_bufq(const struct idpf_vport *vport,\n--\ndrivers/net/ethernet/intel/idpf/xsk.c-29-\tconst struct idpf_q_vec_rsrc *rsrc = \u0026vport-\u003edflt_qv_rsrc;\ndrivers/net/ethernet/intel/idpf/xsk.c:30:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/xsk.c-31-\tu32 qid = U32_MAX;\n--\ndrivers/net/ethernet/intel/idpf/xsk.c=54=static void idpf_xsk_setup_txq(const struct idpf_vport *vport,\n--\ndrivers/net/ethernet/intel/idpf/xsk.c-56-{\ndrivers/net/ethernet/intel/idpf/xsk.c:57:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/xsk.c-58-\tu32 qid;\n--\ndrivers/net/ethernet/intel/idpf/xsk.c=79=static void idpf_xsk_setup_complq(const struct idpf_vport *vport,\n--\ndrivers/net/ethernet/intel/idpf/xsk.c-81-{\ndrivers/net/ethernet/intel/idpf/xsk.c:82:\tconst struct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/idpf/xsk.c-83-\tu32 qid;\n--\ndrivers/net/ethernet/intel/idpf/xsk.c=554=int idpf_xsk_pool_setup(struct idpf_vport *vport, struct netdev_bpf *bpf)\ndrivers/net/ethernet/intel/idpf/xsk.c-555-{\ndrivers/net/ethernet/intel/idpf/xsk.c:556:\tstruct xsk_buff_pool *pool = bpf-\u003exsk.pool;\ndrivers/net/ethernet/intel/idpf/xsk.c-557-\tu32 qid = bpf-\u003exsk.queue_id;\n--\ndrivers/net/ethernet/intel/igb/igb.h=319=struct igb_ring {\n--\ndrivers/net/ethernet/intel/igb/igb.h-364-\tstruct xdp_rxq_info xdp_rxq;\ndrivers/net/ethernet/intel/igb/igb.h:365:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/igb/igb.h-366-} ____cacheline_internodealigned_in_smp;\n--\ndrivers/net/ethernet/intel/igb/igb.h=859=int igb_del_mac_steering_filter(struct igb_adapter *adapter,\n--\ndrivers/net/ethernet/intel/igb/igb.h-861-\ndrivers/net/ethernet/intel/igb/igb.h:862:struct xsk_buff_pool *igb_xsk_pool(struct igb_adapter *adapter,\ndrivers/net/ethernet/intel/igb/igb.h-863-\t\t\t\t   struct igb_ring *ring);\ndrivers/net/ethernet/intel/igb/igb.h=864=int igb_xsk_pool_setup(struct igb_adapter *adapter,\ndrivers/net/ethernet/intel/igb/igb.h:865:\t\t       struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/igb/igb.h-866-\t\t       u16 qid);\ndrivers/net/ethernet/intel/igb/igb.h=867=bool igb_alloc_rx_buffers_zc(struct igb_ring *rx_ring,\ndrivers/net/ethernet/intel/igb/igb.h:868:\t\t\t     struct xsk_buff_pool *xsk_pool, u16 count);\ndrivers/net/ethernet/intel/igb/igb.h-869-void igb_clean_rx_ring_zc(struct igb_ring *rx_ring);\ndrivers/net/ethernet/intel/igb/igb.h=870=int igb_clean_rx_irq_zc(struct igb_q_vector *q_vector,\ndrivers/net/ethernet/intel/igb/igb.h:871:\t\t\tstruct xsk_buff_pool *xsk_pool, const int budget);\ndrivers/net/ethernet/intel/igb/igb.h:872:bool igb_xmit_zc(struct igb_ring *tx_ring, struct xsk_buff_pool *xsk_pool);\ndrivers/net/ethernet/intel/igb/igb.h-873-int igb_xsk_wakeup(struct net_device *dev, u32 qid, u32 flags);\n--\ndrivers/net/ethernet/intel/igb/igb_main.c=8278=static int igb_poll(struct napi_struct *napi, int budget)\n--\ndrivers/net/ethernet/intel/igb/igb_main.c-8282-\t\t\t\t\t\t     napi);\ndrivers/net/ethernet/intel/igb/igb_main.c:8283:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/igb/igb_main.c-8284-\tbool clean_complete = true;\n--\ndrivers/net/ethernet/intel/igb/igb_main.c=8327=static bool igb_clean_tx_irq(struct igb_q_vector *q_vector, int napi_budget)\n--\ndrivers/net/ethernet/intel/igb/igb_main.c-8335-\tstruct igb_tx_buffer *tx_buffer;\ndrivers/net/ethernet/intel/igb/igb_main.c:8336:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/igb/igb_main.c-8337-\tint cpu = smp_processor_id();\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=57=static void igb_txrx_ring_enable(struct igb_adapter *adapter, u16 qid)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c-82-\ndrivers/net/ethernet/intel/igb/igb_xsk.c:83:struct xsk_buff_pool *igb_xsk_pool(struct igb_adapter *adapter,\ndrivers/net/ethernet/intel/igb/igb_xsk.c-84-\t\t\t\t   struct igb_ring *ring)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c-86-\tint qid = ring-\u003equeue_index;\ndrivers/net/ethernet/intel/igb/igb_xsk.c:87:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/igb/igb_xsk.c-88-\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=97=static int igb_xsk_pool_enable(struct igb_adapter *adapter,\ndrivers/net/ethernet/intel/igb/igb_xsk.c:98:\t\t\t       struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/igb/igb_xsk.c-99-\t\t\t       u16 qid)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=139=static int igb_xsk_pool_disable(struct igb_adapter *adapter, u16 qid)\ndrivers/net/ethernet/intel/igb/igb_xsk.c-140-{\ndrivers/net/ethernet/intel/igb/igb_xsk.c:141:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/igb/igb_xsk.c-142-\tstruct igb_ring *rx_ring;\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=168=int igb_xsk_pool_setup(struct igb_adapter *adapter,\ndrivers/net/ethernet/intel/igb/igb_xsk.c:169:\t\t       struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/igb/igb_xsk.c-170-\t\t       u16 qid)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c-175-\ndrivers/net/ethernet/intel/igb/igb_xsk.c:176:static u16 igb_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,\ndrivers/net/ethernet/intel/igb/igb_xsk.c-177-\t\t\t     union e1000_adv_rx_desc *rx_desc, u16 count)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=200=bool igb_alloc_rx_buffers_zc(struct igb_ring *rx_ring,\ndrivers/net/ethernet/intel/igb/igb_xsk.c:201:\t\t\t     struct xsk_buff_pool *xsk_pool, u16 count)\ndrivers/net/ethernet/intel/igb/igb_xsk.c-202-{\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=294=static int igb_run_xdp_zc(struct igb_adapter *adapter, struct igb_ring *rx_ring,\ndrivers/net/ethernet/intel/igb/igb_xsk.c:295:\t\t\t  struct xdp_buff *xdp, struct xsk_buff_pool *xsk_pool,\ndrivers/net/ethernet/intel/igb/igb_xsk.c-296-\t\t\t  struct bpf_prog *xdp_prog)\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c=341=int igb_clean_rx_irq_zc(struct igb_q_vector *q_vector,\ndrivers/net/ethernet/intel/igb/igb_xsk.c:342:\t\t\tstruct xsk_buff_pool *xsk_pool, const int budget)\ndrivers/net/ethernet/intel/igb/igb_xsk.c-343-{\n--\ndrivers/net/ethernet/intel/igb/igb_xsk.c-464-\ndrivers/net/ethernet/intel/igb/igb_xsk.c:465:bool igb_xmit_zc(struct igb_ring *tx_ring, struct xsk_buff_pool *xsk_pool)\ndrivers/net/ethernet/intel/igb/igb_xsk.c-466-{\n--\ndrivers/net/ethernet/intel/igc/igc.h=148=struct igc_ring {\n--\ndrivers/net/ethernet/intel/igc/igc.h-204-\tstruct xdp_rxq_info xdp_rxq;\ndrivers/net/ethernet/intel/igc/igc.h:205:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/igc/igc.h-206-} ____cacheline_internodealigned_in_smp;\n--\ndrivers/net/ethernet/intel/igc/igc_main.c=597=static int igc_setup_all_rx_resources(struct igc_adapter *adapter)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c-614-\ndrivers/net/ethernet/intel/igc/igc_main.c:615:static struct xsk_buff_pool *igc_get_xsk_pool(struct igc_adapter *adapter,\ndrivers/net/ethernet/intel/igc/igc_main.c-616-\t\t\t\t\t      struct igc_ring *ring)\n--\ndrivers/net/ethernet/intel/igc/igc_main.c=3034=static void igc_xdp_xmit_zc(struct igc_ring *ring)\ndrivers/net/ethernet/intel/igc/igc_main.c-3035-{\ndrivers/net/ethernet/intel/igc/igc_main.c:3036:\tstruct xsk_buff_pool *pool = ring-\u003exsk_pool;\ndrivers/net/ethernet/intel/igc/igc_main.c-3037-\tstruct netdev_queue *nq = txring_txq(ring);\n--\ndrivers/net/ethernet/intel/igc/igc_ptp.c=749=static void igc_ptp_tx_reg_to_stamp(struct igc_adapter *adapter,\n--\ndrivers/net/ethernet/intel/igc/igc_ptp.c-782-\tif (tstamp-\u003ebuffer_type == IGC_TX_BUFFER_TYPE_XSK) {\ndrivers/net/ethernet/intel/igc/igc_ptp.c:783:\t\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/ethernet/intel/igc/igc_ptp.c-784-\n--\ndrivers/net/ethernet/intel/igc/igc_xdp.c=56=static int igc_xdp_enable_pool(struct igc_adapter *adapter,\ndrivers/net/ethernet/intel/igc/igc_xdp.c:57:\t\t\t       struct xsk_buff_pool *pool, u16 queue_id)\ndrivers/net/ethernet/intel/igc/igc_xdp.c-58-{\n--\ndrivers/net/ethernet/intel/igc/igc_xdp.c=118=static int igc_xdp_disable_pool(struct igc_adapter *adapter, u16 queue_id)\n--\ndrivers/net/ethernet/intel/igc/igc_xdp.c-120-\tstruct igc_ring *rx_ring, *tx_ring;\ndrivers/net/ethernet/intel/igc/igc_xdp.c:121:\tstruct xsk_buff_pool *pool;\ndrivers/net/ethernet/intel/igc/igc_xdp.c-122-\tstruct napi_struct *napi;\n--\ndrivers/net/ethernet/intel/igc/igc_xdp.c-158-\ndrivers/net/ethernet/intel/igc/igc_xdp.c:159:int igc_xdp_setup_pool(struct igc_adapter *adapter, struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/igc/igc_xdp.c-160-\t\t       u16 queue_id)\n--\ndrivers/net/ethernet/intel/igc/igc_xdp.h=7=int igc_xdp_set_prog(struct igc_adapter *adapter, struct bpf_prog *prog,\ndrivers/net/ethernet/intel/igc/igc_xdp.h-8-\t\t     struct netlink_ext_ack *extack);\ndrivers/net/ethernet/intel/igc/igc_xdp.h:9:int igc_xdp_setup_pool(struct igc_adapter *adapter, struct xsk_buff_pool *pool,\ndrivers/net/ethernet/intel/igc/igc_xdp.h-10-\t\t       u16 queue_id);\n--\ndrivers/net/ethernet/intel/ixgbe/ixgbe.h=357=struct ixgbe_ring {\n\n"
}
27/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 35756
							output: 40
							thoughts: 123

Thoughts: 
**Investigating XSK Buffer Pool Usage in Virtual Drivers**

Alright, so `xsk_buff_pool` is a pretty ubiquitous thing, isn't it? Shows up all over the place in drivers. I need to figure out which of these drivers that use it are actually virtual ones. Let's see... I've got `tsnep`, which is that Time Sensitive Networking Endpoint FPGA thing... nope. `dpaa2`, Freescale's Data Path Acceleration Architecture - nah, not virtual. Okay, `fec`, the Fast Ethernet Controller from Freescale - still no dice. Ah, hold on... there's `gve`, Google Virtual Ethernet. Yes! *That's* a virtual driver. Now the interesting part. Let's find out if `gve` is leveraging either `xsk_buff_get_metadata` or the old `xp_raw_get_ctx`. That'll tell us something about how it's interacting with the underlying structures.

28/2 2026/08/10 22:38 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_get_metadata",
  "PathPrefix": "drivers/net/ethernet/google/gve/"
}

Results: 
{
  "error": "no matches"
}
29/2 2026/08/10 22:38 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 36142
							output: 39
							thoughts: 18

Thoughts: 
Here's my take on those thoughts:

**Analyzing `xp_raw_get_ctx` within `gve`**

Okay, so the immediate focus is on `xp_raw_get_ctx` – I need to understand its role and behavior within the `gve` context. This likely means I'm looking for how this function interacts with the overall graphics virtualization environment, or potentially some core rendering or context management piece. My first step is probably to pull up the code for that function and quickly review its purpose. I'll be looking for what data it receives and returns. What are the key operations it performs? Is it involved in creating, retrieving, or managing any critical handles or objects related to graphics resources? Are there any obvious areas of concern like potential race conditions or performance bottlenecks? I will be paying close attention to any external dependencies and how this function potentially influences the performance, stability and general behaviour of the system. Let's see what we can find.

30/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xp_raw_get_ctx",
  "PathPrefix": "drivers/net/ethernet/google/gve/"
}

Results: 
{
  "error": "no matches"
}
31/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 36416
							output: 40
							thoughts: 19

Thoughts: 
Okay, let's dive into this. Here's my thought process on what we're looking at, summarized from the initial prompt:

**Analyzing `xsk_tx_metadata_request` in `gve`**

Alright, my brain just kicked into gear. The initial prompt is pretty clear: it's directing me to examine the `xsk_tx_metadata_request` component within the `gve` context. This likely means we're dealing with aspects of the Generic Virtual Ethernet (GVE) driver and, more specifically, how it handles the transmission (TX) side of things in the XDP (eXpress Data Path) world, with metadata requests. My assumption is that this request pertains to specific details or supplementary information related to the packets being sent through the XDP socket. Perhaps it's dealing with VLAN tagging, queue assignment, checksum offload directives, or something along those lines? My first step will be to confirm these suspicions by checking the codebase and finding out exactly what type of "metadata" the request encompasses. I will pay particular attention to the data structures involved, the functions that consume the request, and how it fits into the overall TX path. Let's see what the code tells us!

32/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata_request",
  "PathPrefix": "drivers/net/ethernet/google/gve/"
}

Results: 
{
  "error": "no matches"
}
33/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 36747
							output: 36
							thoughts: 19

Thoughts: 
Okay, here's my summary, framed as my internal thought process:

**Network Driver Deep Dive: Examining `virtio_net` and XDP**

Right, let's see. I'm thinking specifically about `virtio_net` right now. A key question is immediately coming to mind: does this particular driver offer support for AF_XDP and its zero-copy capabilities? That's a critical detail for performance in high-throughput network environments, so it's the first thing I'd want to verify. It would be great if it did! If not, what would it take to implement? Let me dig a little further...

34/2 2026/08/10 22:39 tool grepper
0m Args: 
{
  "Expression": "xsk_buff_pool",
  "PathPrefix": "drivers/net/virtio_net.c"
}

Results: 
{
  "Output": "drivers/net/virtio_net.c=295=struct send_queue {\n--\ndrivers/net/virtio_net.c-313-\ndrivers/net/virtio_net.c:314:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/virtio_net.c-315-\n--\ndrivers/net/virtio_net.c=320=struct receive_queue {\n--\ndrivers/net/virtio_net.c-367-\ndrivers/net/virtio_net.c:368:\tstruct xsk_buff_pool *xsk_pool;\ndrivers/net/virtio_net.c-369-\n--\ndrivers/net/virtio_net.c=1322=static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue *rq,\ndrivers/net/virtio_net.c:1323:\t\t\t\t   struct xsk_buff_pool *pool, gfp_t gfp)\ndrivers/net/virtio_net.c-1324-{\n--\ndrivers/net/virtio_net.c=1384=static int virtnet_xsk_xmit_one(struct send_queue *sq,\ndrivers/net/virtio_net.c:1385:\t\t\t\tstruct xsk_buff_pool *pool,\ndrivers/net/virtio_net.c-1386-\t\t\t\tstruct xdp_desc *desc)\n--\ndrivers/net/virtio_net.c=1405=static int virtnet_xsk_xmit_batch(struct send_queue *sq,\ndrivers/net/virtio_net.c:1406:\t\t\t\t  struct xsk_buff_pool *pool,\ndrivers/net/virtio_net.c-1407-\t\t\t\t  unsigned int budget,\n--\ndrivers/net/virtio_net.c-1436-\ndrivers/net/virtio_net.c:1437:static bool virtnet_xsk_xmit(struct send_queue *sq, struct xsk_buff_pool *pool,\ndrivers/net/virtio_net.c-1438-\t\t\t     int budget)\n--\ndrivers/net/virtio_net.c=5820=static int virtnet_rq_bind_xsk_pool(struct virtnet_info *vi, struct receive_queue *rq,\ndrivers/net/virtio_net.c:5821:\t\t\t\t    struct xsk_buff_pool *pool)\ndrivers/net/virtio_net.c-5822-{\n--\ndrivers/net/virtio_net.c=5861=static int virtnet_sq_bind_xsk_pool(struct virtnet_info *vi,\ndrivers/net/virtio_net.c-5862-\t\t\t\t    struct send_queue *sq,\ndrivers/net/virtio_net.c:5863:\t\t\t\t    struct xsk_buff_pool *pool)\ndrivers/net/virtio_net.c-5864-{\n--\ndrivers/net/virtio_net.c=5885=static int virtnet_xsk_pool_enable(struct net_device *dev,\ndrivers/net/virtio_net.c:5886:\t\t\t\t   struct xsk_buff_pool *pool,\ndrivers/net/virtio_net.c-5887-\t\t\t\t   u16 qid)\n--\ndrivers/net/virtio_net.c=5969=static int virtnet_xsk_pool_disable(struct net_device *dev, u16 qid)\n--\ndrivers/net/virtio_net.c-5971-\tstruct virtnet_info *vi = netdev_priv(dev);\ndrivers/net/virtio_net.c:5972:\tstruct xsk_buff_pool *pool;\ndrivers/net/virtio_net.c-5973-\tstruct receive_queue *rq;\n"
}
35/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 37925
							output: 38
							thoughts: 40

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

**Virtio-net & XDP: Delving into Zero-Copy Implementation**

Alright, *virtio_net* now supporting AF_XDP zero-copy is great news. My immediate question, though, is how precisely they've implemented it. Are they leaning towards using the *xsk_tx_metadata_request* or the *xsk_buff_get_metadata* function? That's the crux of this. Understanding the choice here gives me a deeper sense of the approach, the trade-offs they made, and potential implications for performance. Is this a more efficient pull-based approach, or did they go with something else? We can learn a lot from this detail.

36/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata_request",
  "PathPrefix": "drivers/net/virtio_net.c"
}

Results: 
{
  "error": "no matches"
}
37/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 38184
							output: 38
							thoughts: 33

Thoughts: 
Okay, let's dive into this. Here's how I'd approach this task, as if these were my internal thoughts:

**Investigating Potential Data Retrieval Points in virtio_net.c**

Alright, I'm thinking we need to trace where we're getting our data from in the `virtio_net.c` module. My immediate instinct is to look at how the context or metadata for the XSK (eXpress Data Path Socket Kernel) buffers are handled. We're obviously concerned about data retrieval, and since we're using XSK, the functions to examine are likely `xp_raw_get_ctx` or `xsk_buff_get_metadata` within that file. That's the most logical starting point for understanding how the relevant data is being accessed and prepared for processing. I'll need to understand how the context is being retrieved or how the buffer metadata is being made available.

38/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_get_metadata",
  "PathPrefix": "drivers/net/virtio_net.c"
}

Results: 
{
  "error": "no matches"
}
39/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 38466
							output: 37
							thoughts: 22

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

**Diving into virtio_net.c**

Alright, time to dig in. The problem likely lies in the interaction between the driver and the Xen platform. The function `xp_raw_get_ctx` is the specific piece I need to look at in `virtio_net.c`. I have a hunch that this is where the context data is being retrieved or handled, and that's where the failure is occurring. Let's see how that function is implemented and how it's used within the virtio_net context. I expect this to be a crucial data retrieval step.

40/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xp_raw_get_ctx",
  "PathPrefix": "drivers/net/virtio_net.c"
}

Results: 
{
  "error": "no matches"
}
41/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 38680
							output: 34
							thoughts: 34

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

**Investigating AF_XDP TX Metadata Support**

Alright, let's see, the `virtio_net` driver is apparently not playing ball with AF_XDP TX metadata. That's a bit of a wrinkle in my current project, as I was hoping to leverage that functionality. Time to pivot. Okay, what about the `netdevsim` driver? It's often a useful testing ground. Does *it* provide the necessary support for AF_XDP? Specifically, does it handle that crucial metadata during transmission? I need to check the docs, maybe run a quick test. This could open up a viable path forward, or at least help me understand the potential limitations.

42/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_pool",
  "PathPrefix": "drivers/net/netdevsim/"
}

Results: 
{
  "error": "no matches"
}
43/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 38924
							output: 40
							thoughts: 278

Thoughts: 
**My Current Thinking on AF_XDP TX Metadata Support**

Okay, so I'm trying to figure out which network drivers support AF_XDP TX metadata. I *did* check `veth` already – nothing there, no `xsk_buff_pool`. So, let's see, my notes say the following drivers have support: `igc` (the Intel I225/I226), `mlx5` (Mellanox ConnectX-4+), `stmmac` (the STMicroelectronics MAC), and `idpf` (the Intel Infrastructure Data Path Function).

Wait a minute, wasn’t `stmmac` used in *some* QEMU emulations? No, that's not right. `stmmac` is typically for ARM SoCs, like Synopsys DesignWare MAC. QEMU doesn't emulate it by default on x86, but it *can* be used to emulate some ARM boards.

Hold on… I'm getting mixed up. I also thought `igc` was emulated in QEMU, but that's not right, is it? QEMU has the `e1000` and `e1000e` emulations. But `e1000e` is not the same as `igb`, right? No, `e1000e` is the `e1000e` driver and `igb` is for the 82575/82576. Ah, that's right, QEMU has `igb` emulation!

Now I need to check something important. Does `igb` support AF_XDP TX metadata? I need to look that up and verify.

44/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata_request",
  "PathPrefix": "drivers/net/ethernet/intel/igb/"
}

Results: 
{
  "error": "no matches"
}
45/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 39636
							output: 44
							thoughts: 29

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

**Examining eBPF XSK TX Support**

Alright, so I'm digging into the specifics of eBPF and XSK TX, and it looks like `igb` driver isn't playing nicely with `xsk_tx_metadata_request`. That's a bit of a bummer; I'll have to keep that in mind. Now, let's pivot. Since `igb` is out of the picture for that specific use case, my next thought is, what about `e1000e`? I wonder if that driver offers better support. I'll need to check the kernel source or relevant documentation to see if it provides the requested functionality. This could be a good alternative, or at least a stepping stone to a solution. Perhaps the `e1000e` code offers a similar architecture that is more readily adapted. Time to delve a bit deeper and see what I can find.

46/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata_request",
  "PathPrefix": "drivers/net/ethernet/intel/e1000e/"
}

Results: 
{
  "error": "no matches"
}
47/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 39943
							output: 42
							thoughts: 345

Thoughts: 
**My Assessment of XDP Support**

Okay, so I'm looking at XDP support and it seems only `igc`, `mlx5`, `stmmac`, and `idpf` are the drivers in play. Hmm, let me think through `idpf` a bit closer. It looks like `idpf` leverages `libeth_xsk_xmit_do_bulk`, which then calls `libeth_xsk_xmit_fill_buf_md`, which, finally, calls `xsk_tx_metadata_request`. I'm going to quickly check if these drivers are emulated by QEMU. Nope, `idpf` isn't emulated in QEMU. Neither is `mlx5`, or `igc`. Now, `stmmac`... QEMU has those device definitions: `hw/net/allwinner-sun8i-emac.c`, `hw/net/imx_fec.c`, `hw/net/cadence_gem.c`, `hw/net/ftgmac100.c`, `hw/net/npcm7xx_emc.c`.

Aha, `stmmac` is a driver for Synopsys DesignWare MAC (DWMAC)! And QEMU does emulate `designware` MAC! That's good news. Time to double-check that QEMU has `designware`. Yep, there it is: `hw/net/designware.c`. The remaining question is, is this accessible in the standard syzkaller x86_64 VMs? Syzkaller uses `qemu-system-x86_64`. I need to figure out how `designware` MAC is exposed in these environments, typically, is it a platform device on ARM or a PCI device? Okay, I should check if `stmmac` can be a PCI device.

48/2 2026/08/10 22:39 tool grepper
0m Args: 
{
  "Expression": "stmmac_pci_info",
  "PathPrefix": "drivers/net/ethernet/stmicro/stmmac/"
}

Results: 
{
  "Output": "drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=45=struct stmmac_pci_dmi_data {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-49-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:50:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-51-\tint (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=786=static int ehl_sgmii_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-805-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:806:static struct stmmac_pci_info ehl_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-807-\t.setup = ehl_sgmii_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=810=static int ehl_rgmii_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-820-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:821:static struct stmmac_pci_info ehl_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-822-\t.setup = ehl_rgmii_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=841=static int ehl_pse0_rgmii1g_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-847-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:848:static struct stmmac_pci_info ehl_pse0_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-849-\t.setup = ehl_pse0_rgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=852=static int ehl_pse0_sgmii1g_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-869-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:870:static struct stmmac_pci_info ehl_pse0_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-871-\t.setup = ehl_pse0_sgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=890=static int ehl_pse1_rgmii1g_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-896-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:897:static struct stmmac_pci_info ehl_pse1_rgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-898-\t.setup = ehl_pse1_rgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=901=static int ehl_pse1_sgmii1g_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-918-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:919:static struct stmmac_pci_info ehl_pse1_sgmii1g_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-920-\t.setup = ehl_pse1_sgmii1g_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=944=static int tgl_sgmii_phy0_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-952-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:953:static struct stmmac_pci_info tgl_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-954-\t.setup = tgl_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=957=static int tgl_sgmii_phy1_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-965-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:966:static struct stmmac_pci_info tgl_sgmii1g_phy1_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-967-\t.setup = tgl_sgmii_phy1_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=970=static int adls_sgmii_phy0_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-979-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:980:static struct stmmac_pci_info adls_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-981-\t.setup = adls_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=984=static int adls_sgmii_phy1_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-993-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:994:static struct stmmac_pci_info adls_sgmii1g_phy1_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-995-\t.setup = adls_sgmii_phy1_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1023=static int adln_sgmii_phy0_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1041-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1042:static struct stmmac_pci_info adln_sgmii1g_phy0_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1043-\t.setup = adln_sgmii_phy0_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1109=static int quark_default_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1144-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1145:static const struct stmmac_pci_info quark_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1146-\t.setup = quark_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c=1263=static int intel_eth_pci_probe(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1265-{\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c:1266:\tstruct stmmac_pci_info *info = (struct stmmac_pci_info *)id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-intel.c-1267-\tstruct intel_priv_data *intel_priv;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=76=struct loongson_data {\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-81-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:82:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-83-\tint (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=132=static int loongson_gmac_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-141-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:142:static struct stmmac_pci_info loongson_gmac_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-143-\t.setup = loongson_gmac_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=165=static int loongson_gnet_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-176-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:177:static struct stmmac_pci_info loongson_gnet_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-178-\t.setup = loongson_gnet_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c=498=static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id)\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-501-\tstruct stmmac_resources res = {};\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:502:\tstruct stmmac_pci_info *info;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-503-\tstruct loongson_data *ld;\n--\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-542-\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:543:\tinfo = (struct stmmac_pci_info *)id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c-544-\tret = info-\u003esetup(pdev, plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-18-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:19:struct stmmac_pci_info {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-20-\tint (*setup)(struct pci_dev *pdev, struct plat_stmmacenet_data *plat);\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=33=static int stmmac_default_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-49-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:50:static const struct stmmac_pci_info stmmac_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-51-\t.setup = stmmac_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=54=static int snps_gmac5_default_data(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-101-\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:102:static const struct stmmac_pci_info snps_gmac5_pci_info = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-103-\t.setup = snps_gmac5_default_data,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=118=static int stmmac_pci_probe(struct pci_dev *pdev,\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-120-{\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:121:\tstruct stmmac_pci_info *info = (struct stmmac_pci_info *)id-\u003edriver_data;\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-122-\tstruct plat_stmmacenet_data *plat;\n--\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c=203=static const struct pci_device_id stmmac_id_table[] = {\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:204:\t{ PCI_DEVICE_DATA(STMMAC, STMMAC, \u0026stmmac_pci_info) },\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:205:\t{ PCI_DEVICE_DATA(STMICRO, MAC, \u0026stmmac_pci_info) },\ndrivers/net/ethernet/stmicro/stmmac/stmmac_pci.c-206-\t{ PCI_DEVICE_DATA(SYNOPSYS, GMAC5_ID, \u0026snps_gmac5_pci_info) },\n"
}
49/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 44743
							output: 36
							thoughts: 604

Thoughts: 
**Analyzing the AF_XDP TX Metadata Patch**

Okay, so I'm looking at this patch and my initial thought is, "Yes, `stmmac` *can* be a PCI device, like with `dwmac-intel.c` and `stmmac_pci.c`." But then I remember `stmmac` is also used for Intel Quark and other Intel SoCs, so is this something I can even reach with Syzkaller? Syzkaller uses `qemu-system-x86_64`, which can inject PCI devices *if* QEMU supports them. And, unfortunately, I know QEMU doesn't emulate `stmmac` PCI devices.

Okay, back to the drawing board. Let's think about `veth`. Hmm, I checked `veth` earlier, and it doesn't support AF_XDP TX metadata.

Wait a second! This patch is modifying `__xsk_buff_get_metadata` in `include/net/xdp_sock_drv.h`. Specifically, this change:
```c
 static inline struct xsk_tx_metadata *
-__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data)
+__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,
+			unsigned int options)
 {
-	if (!pool->tx_metadata_len)
+	if (!pool->tx_metadata_len || !(options & XDP_TX_METADATA))
 		return NULL;
```
This function is crucial, as it's called by `xsk_buff_get_metadata` and `xp_raw_get_ctx`. Now, `xp_raw_get_ctx` leads to `xsk_buff_raw_get_ctx`, which leads to `__libeth_xsk_xmit_fill_buf_md`. And that, in turn, is used in `libeth_xsk_xmit_fill_buf`, which is used in `libeth_xsk_xmit_do_bulk`. Finally, `libeth_xsk_xmit_do_bulk` is used in `idpf_xsk_xmit`.

Wait! I see that `xsk_buff_get_metadata` is also called directly in `igc_xdp_xmit_zc`, `mlx5e_xsk_tx`, and `stmmac_xdp_xmit_zc`. These all look promising. Now, can any of those be reached with Syzkaller?

Syzkaller *can* fuzz AF_XDP sockets. But if the underlying driver doesn't support AF_XDP zero copy *or* TX metadata, that code in `__xsk_buff_get_metadata` might not even get hit. Hmmm, does `veth` support AF_XDP zero copy? I'll need to check `veth_xdp_xmit` and see.

50/2 2026/08/10 22:39 tool grepper
0m Args: 
{
  "Expression": "veth_xdp_xmit",
  "PathPrefix": "drivers/net/veth.c"
}

Results: 
{
  "Output": "drivers/net/veth.c=496=static struct net_device *veth_peer_dev(struct net_device *dev)\n--\ndrivers/net/veth.c-503-\ndrivers/net/veth.c:504:static int veth_xdp_xmit(struct net_device *dev, int n,\ndrivers/net/veth.c-505-\t\t\t struct xdp_frame **frames,\n--\ndrivers/net/veth.c=561=static int veth_ndo_xdp_xmit(struct net_device *dev, int n,\n--\ndrivers/net/veth.c-565-\ndrivers/net/veth.c:566:\terr = veth_xdp_xmit(dev, n, frames, flags, true);\ndrivers/net/veth.c-567-\tif (err \u003c 0) {\n--\ndrivers/net/veth.c=576=static void veth_xdp_flush_bq(struct veth_rq *rq, struct veth_xdp_tx_bq *bq)\n--\ndrivers/net/veth.c-579-\ndrivers/net/veth.c:580:\tsent = veth_xdp_xmit(rq-\u003edev, bq-\u003ecount, bq-\u003eq, 0, false);\ndrivers/net/veth.c-581-\tif (sent \u003c 0) {\n"
}
51/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 46418
							output: 21
							thoughts: 105

Thoughts: 
**Analyzing veth and AF_XDP Support**

Okay, so I'm looking at `veth` and how it handles XDP and AF_XDP. It's clear that it implements `ndo_xdp_xmit`, which is expected. However, it *doesn't* implement either `ndo_xsk_wakeup` or `ndo_bpf` with `XDP_SETUP_XSK_POOL`. Hmm, that suggests something specific about its AF_XDP support.

Ah, right, now it's clicking. `veth` supports AF_XDP but in *copy* mode, not zero-copy. That's why those other callbacks aren't implemented. In copy mode, the AF_XDP traffic would be handled with something like `xsk_generic_xmit`, or something functionally equivalent, right? That's the expected path. Let me double-check `xsk_generic_xmit` now to confirm my assumptions and ensure the data flow is understood.

52/2 2026/08/10 22:39 tool grepper
0m Args: 
{
  "Expression": "xsk_generic_xmit"
}

Results: 
{
  "Output": "include/net/xdp_sock.h=48=struct xdp_sock {\n--\ninclude/net/xdp_sock.h-77-\ninclude/net/xdp_sock.h:78:\t/* When __xsk_generic_xmit() must return before it sees the EOP descriptor for the current\ninclude/net/xdp_sock.h-79-\t * packet, the partially built skb is saved here so that packet building can resume in next\ninclude/net/xdp_sock.h:80:\t * call of __xsk_generic_xmit().\ninclude/net/xdp_sock.h-81-\t */\n--\nnet/xdp/xsk.c=1085=static struct sk_buff *xsk_build_skb(struct xdp_sock *xs,\n--\nnet/xdp/xsk.c-1190-\nnet/xdp/xsk.c:1191:static int __xsk_generic_xmit(struct sock *sk)\nnet/xdp/xsk.c-1192-{\n--\nnet/xdp/xsk.c-1305-\nnet/xdp/xsk.c:1306:static int xsk_generic_xmit(struct sock *sk)\nnet/xdp/xsk.c-1307-{\n--\nnet/xdp/xsk.c-1311-\trcu_read_unlock();\nnet/xdp/xsk.c:1312:\tret = __xsk_generic_xmit(sk);\nnet/xdp/xsk.c-1313-\t/* Reaquire RCU lock before going into common code. */\n--\nnet/xdp/xsk.c=1340=static int __xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)\n--\nnet/xdp/xsk.c-1365-\t\t\treturn xsk_wakeup(xs, XDP_WAKEUP_TX);\nnet/xdp/xsk.c:1366:\t\treturn xsk_generic_xmit(sk);\nnet/xdp/xsk.c-1367-\t}\n--\nnet/xdp/xsk.c=1419=static __poll_t xsk_poll(struct file *file, struct socket *sock,\n--\nnet/xdp/xsk.c-1439-\t\t\t/* Poll needs to drive Tx also in copy mode */\nnet/xdp/xsk.c:1440:\t\t\txsk_generic_xmit(sk);\nnet/xdp/xsk.c-1441-\t}\n--\nnet/xdp/xsk.c=2240=static int __init xsk_init(void)\n--\nnet/xdp/xsk.c-2259-\nnet/xdp/xsk.c:2260:\txsk_tx_generic_cache = kmem_cache_create(\"xsk_generic_xmit_cache\",\nnet/xdp/xsk.c-2261-\t\t\t\t\t\t sizeof(struct xsk_addrs),\n--\ntools/testing/selftests/bpf/prog_tests/test_xsk.c=898=static bool kick_tx_with_check(struct xsk_socket_info *xsk, int *ret)\n--\ntools/testing/selftests/bpf/prog_tests/test_xsk.c-910-\t * send in this case where hitting the max budget limit in while\ntools/testing/selftests/bpf/prog_tests/test_xsk.c:911:\t * loop is triggered in __xsk_generic_xmit(). Please make sure that\ntools/testing/selftests/bpf/prog_tests/test_xsk.c-912-\t * the number of descs to be sent is larger than @max_budget, or\n"
}
53/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 47734
							output: 37
							thoughts: 33

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

**Investigating the Data Retrieval Path in `__xsk_generic_xmit`**

Alright, so I'm digging into the internals of the XDP transmit path, specifically within `__xsk_generic_xmit`. The key question I need to answer is: how is the metadata actually retrieved for each buffer that is being sent? Is it using `xsk_buff_get_metadata` or is it using `xp_raw_get_ctx` ? The distinction matters because each function may have slightly different memory access patterns, different concurrency implications, or even different versions available. Understanding this exact step is crucial for optimising performance, looking for potential bottlenecks, and for any low level debugging I'm going to be doing. I need to trace this function as it is the heart of any performance improvement I am attempting. This impacts my understanding of the data access patterns and memory barriers. The answer will directly influence how I think about potential lock contention or data dependency issues. Now, I have to determine which of these functions it is actually using. Time to get to the code.

54/2 2026/08/10 22:39 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_buff_get_metadata",
  "PathPrefix": "net/xdp/xsk.c"
}

Results: 
{
  "error": "no matches"
}
55/2 2026/08/10 22:39 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 48064
							output: 36
							thoughts: 25

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

**Diving into the XDP/XSK Depths**

Okay, so we're talking about an XSK context, and I need to figure out how it's being retrieved at the kernel level. Time to head straight to the source. Let's start by zeroing in on `xp_raw_get_ctx` within `net/xdp/xsk.c`. That function name just *screams* "this is where the magic happens," right? This should provide the foundational mechanism for accessing the XSK context; it’s likely the core operation we're interested in. Knowing this function's logic will give me a solid grasp of how this raw XSK access is functioning, its dependencies, and any potential points of contention or optimization. I expect it to have the crucial pieces to get the metadata that’s needed. Time to dig in and see what's actually going on.

56/2 2026/08/10 22:40 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xp_raw_get_ctx",
  "PathPrefix": "net/xdp/xsk.c"
}

Results: 
{
  "error": "no matches"
}
57/2 2026/08/10 22:40 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 48348
							output: 37
							thoughts: 13

Thoughts: 
Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it were my own internal monologue:

**Thinking Through XDP/AF_XDP Transmit Metadata**

Alright, I'm diving into the transmission side of XDP/AF_XDP again. I'm focusing on performance optimization. I've been considering different ways to handle the metadata attached to each packet, specifically for transmit operations. The core question that's bubbling to the surface is about the mechanism for requesting and providing that transmit metadata. It's a critical component for steering packets, applying QoS, and generally getting the most out of hardware offload capabilities.

So, *`xsk_tx_metadata_request`*... What are the specifics? Are we talking about a dedicated structure passed in the ring, or some other mechanism? Does it make sense to have a separate ring for metadata requests, or should it be embedded within the existing TX ring entry? What are the implications in terms of data structures? Is the *`xsk_tx_metadata_request`* specific to the networking stack in use? What about NIC-specific metadata considerations?

I'm thinking about the balance between flexibility and overhead here. A rich metadata structure could offer amazing control, but would likely impose a significant cost in terms of CPU cycles and memory bandwidth. It also needs to be compatible with a broad range of hardware. A simplified interface might be faster but would potentially limit the features we could expose to the userspace application. I need to weigh the trade-offs: How can we give userspace the control it needs, without tanking performance? I'm hoping to craft a design that is performant, extensible, and doesn't introduce too much complexity. It's that balance I need to strike to ensure the architecture scales well. I want to build a truly efficient, flexible system.

58/2 2026/08/10 22:40 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata_request",
  "PathPrefix": "net/xdp/xsk.c"
}

Results: 
{
  "error": "no matches"
}
59/2 2026/08/10 22:40 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 48806
							output: 36
							thoughts: 832

Thoughts: 
**Analyzing AF_XDP TX Metadata Reachability**

Okay, so I'm trying to figure out if this patch actually impacts anything in a typical testing setup. The code in question, `xsk_generic_xmit`, doesn't use TX metadata. That's a key point. TX metadata is *only* supported in zero-copy AF_XDP mode. Right, and zero-copy AF_XDP is limited to a handful of drivers: `igc`, `mlx5`, `stmmac`, and `idpf`.

But wait, `stmmac`... isn't that emulated by QEMU? I should check if that's even a viable path in syzkaller. Syzkaller uses `qemu-system-x86_64`, so the question becomes, does QEMU emulate an `stmmac` device *for x86_64*? No, typically `stmmac` is an ARM/MIPS/RISC-V/Loongson platform device.

Hold on, let me refine that. `dwmac-intel.c` is actually for Intel Quark and some other Intel SoCs like Elkhart Lake, Tiger Lake, and Alder Lake, which are PCI devices. Right, but does QEMU emulate these specific Intel MAC devices? Nope. And what about the others? `igc` (Intel I225/I226)? No, not emulated by QEMU. `mlx5`? Nope. `idpf`? Not emulated either.

Okay, so none of those directly are emulated, so let's try a different approach. Let me search for any other driver that might use `xsk_buff_get_metadata` or `xp_raw_get_ctx`. Let's see... a quick `grep` reveals these uses:

*   `xsk_buff_get_metadata`: `igc_main.c`, `mlx5/tx.c`, `stmmac_main.c`, `xdp_sock_drv.h`, and `xsk_buff_pool.c`.
*   `xp_raw_get_ctx`: `xdp_sock_drv.h`, `xsk_buff_pool.h`, and `xsk_buff_pool.c`.
*   `xsk_buff_raw_get_ctx`: used in `idpf` via `xsk.h`.

So, the modified code is *only* reachable if *one* of those four drivers (`igc`, `mlx5`, `stmmac`, `idpf`) is present and configured for zero-copy AF_XDP. Given the fact that standard QEMU environments used by syzkaller (e.g. `e1000`, `e1000e`, `virtio-net`, etc) don't emulate those drivers, this path is highly unlikely. Any changes here are unreachable in virtualized environments like GCE or the typical QEMU configurations.

Let's do a quick sanity check and rule out any other possibilities. What about `veth`? No, no use of those functions. `macvlan`? Nope. `tun`/`tap`? Negative. What about `virtio_net`? That *does* support zero-copy AF_XDP, but not TX metadata. It's not using those functions. Let me double-check `virtio_net.c` to be absolutely certain... nothing here.

Conclusion: this patch is almost certainly dead code in any standard testing environment.

60/2 2026/08/10 22:40 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata",
  "PathPrefix": "drivers/net/virtio_net.c"
}

Results: 
{
  "error": "no matches"
}
61/2 2026/08/10 22:40 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 50460
							output: 34
							thoughts: 25

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

**Checking for `xsk_tx_metadata` in `netdevsim`**

Right, so I ran a quick search, and... nothing. No immediate hits. That's a little surprising, considering the context. Let me just quickly confirm that. I need to make *absolutely* sure I haven't missed a potential usage. Okay, let's go back and double-check within the `netdevsim` codebase itself. I'll need to meticulously search for every instance of `xsk_tx_metadata`. I know this is a specific function, so a targeted search should be fairly efficient. Gotta be thorough. Even a comment mentioning it is worth noting. Let's dig in.

62/2 2026/08/10 22:40 tool grepper
0m Error: 
no matches

Args: 
{
  "Expression": "xsk_tx_metadata",
  "PathPrefix": "drivers/net/netdevsim/"
}

Results: 
{
  "error": "no matches"
}
63/2 2026/08/10 22:40 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 50697
							output: 23
							thoughts: 553

Thoughts: 
**My Analysis of Reaching the `__xsk_buff_get_metadata` Function**

Okay, so I'm hitting a wall here. There's no straightforward match for the target. Let me rethink this from the ground up. The primary goal is to trigger `__xsk_buff_get_metadata`, which, being an inline function, presents unique challenges.

First, I need to consider `stmmac`. Can I even probe this in QEMU? QEMU *does* have `hw/net/designware.c`, but it's instantiated as a sysbus device, not a PCI device. Hold on though, there's `stmmac_pci.c`, a PCI wrapper for `stmmac`. Could I inject a PCI device using syzkaller, specifically with the vendor ID `PCI_VENDOR_ID_STMICRO` (0x104a) and device ID `PCI_DEVICE_ID_STMICRO_MAC` (0x3798)?

Now, syzkaller *does* have `syz_pci_setup`, if the kernel supports PCI hotplug and the driver is loaded. But, wait, that's not quite right. Syzkaller doesn't actually *emulate* arbitrary PCI devices. It leverages either `vhci` or QEMU's built-in devices, correct? Looking closer, there's no dedicated `syz_pci_setup` pseudo-syscall as I'd have expected, like what exists for USB via `syz_usb_connect`, or wifi with `syz_80211_inject`. For PCI, syzkaller relies on devices present in the VM.

So the core problem becomes this: syzkaller doesn't have a software emulation framework for PCI devices, unlike the USB subsystem. `vfio` is the only alternative, but that's for passing through *real* hardware. So if QEMU doesn't emulate the hardware, I'm stuck.

I need to confirm whether `stmmac` is enabled in syzkaller's default configuration. It usually includes a wide range of drivers, but even if it's present, the `probe` function will fail without the correct hardware (or its emulation in QEMU), and thus, the netdev won't be created. Without the netdev, there is no way to bind an AF_XDP socket. No socket binding means no access to the TX path and thus, no access to `__xsk_buff_get_metadata` directly.

Okay, let's back up. Is there *any* other route to this function? It's inline, in `include/net/xdp_sock_drv.h`, and it's called by `xsk_buff_get_metadata` and `xsk_buff_raw_get_ctx`. Let's explore the callers to those functions to find alternate ways to reach the inline code.

64/2 2026/08/10 22:40 tool grepper
0m Args: 
{
  "Expression": "__xsk_buff_get_metadata"
}

Results: 
{
  "Output": "include/net/xdp_sock_drv.h=321=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:322:__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\ninclude/net/xdp_sock_drv.h-323-\t\t\tunsigned int options)\n--\ninclude/net/xdp_sock_drv.h=332=xsk_buff_get_metadata(struct xsk_buff_pool *pool, u64 addr, u32 options)\ninclude/net/xdp_sock_drv.h-333-{\ninclude/net/xdp_sock_drv.h:334:\treturn __xsk_buff_get_metadata(pool, xp_raw_get_data(pool, addr),\ninclude/net/xdp_sock_drv.h-335-\t\t\t\t       options);\n--\ninclude/net/xdp_sock_drv.h=535=static inline struct xsk_tx_metadata *\ninclude/net/xdp_sock_drv.h:536:__xsk_buff_get_metadata(const struct xsk_buff_pool *pool, void *data,\ninclude/net/xdp_sock_drv.h-537-\t\t\tunsigned int options)\n--\nnet/xdp/xsk_buff_pool.c=775=struct xdp_desc_ctx xp_raw_get_ctx(const struct xsk_buff_pool *pool, u64 addr,\n--\nnet/xdp/xsk_buff_pool.c-782-\tret.dma = __xp_raw_get_dma(pool, addr);\nnet/xdp/xsk_buff_pool.c:783:\tret.meta = __xsk_buff_get_metadata(pool, __xp_raw_get_data(pool, addr),\nnet/xdp/xsk_buff_pool.c-784-\t\t\t\t\t   options);\n"
}
65/2 2026/08/10 22:40 llm patch-evaluator
0m Model: 
gemini-3.1-pro-preview

Args: 
null

Results: 
null

Tokens: 
							input: 52413
							output: 200
							thoughts: 1143

Thoughts: 
**WorthFuzzing=false: Unreachable Code in Virtualized Environments**

Okay, let's break this down. My analysis indicates this patch primarily touches code paths associated with AF_XDP TX metadata and zero-copy, specifically the `xsk_buff_get_metadata` and `xp_raw_get_ctx` functions and their dependents. I've traced these functions and found they are exclusively used by a handful of hardware drivers: `igc` (Intel I225/I226), `mlx5` (Mellanox ConnectX-4+), `stmmac` (STMicroelectronics MAC), and `idpf` (Intel Infrastructure Data Path Function).

Crucially, none of these drivers are virtualized or emulated within the standard QEMU environments that syzkaller, our primary fuzzing tool, typically operates in. I double-checked `igc`, `mlx5`, and `idpf` to confirm they are not emulated, and while `stmmac` *could* theoretically be instantiated via device tree overlays, syzkaller doesn't typically leverage that. My review of the QEMU source confirms that `igc` is not included in the standard QEMU setup and syzkaller uses the `e1000` or `virtio-net` drivers by default.

Now, while the patch *does* touch some include files (`include/net/xdp_sock_drv.h`, `include/net/xsk_buff_pool.h`, `include/uapi/linux/if_xdp.h`) and `net/xdp/xsk_buff_pool.c`, the actual functional changes within these files are limited to inline functions and `xp_raw_get_ctx`. These changes are only reachable via the same hardware drivers mentioned previously. The `include/uapi/linux/if_xdp.h` change adds a `__u32 reserved;` field which is a UAPI change but doesn't, in and of itself, alter any reachable kernel execution flow.

In short, the patch modifies code that's fundamentally inaccessible in our target virtualized environments. The core changes are confined to vendor-specific NIC drivers that require physical hardware not emulated in standard QEMU. The changes in the shared header files and the `net/xdp/xsk_buff_pool.c` file are all transitively only reachable from those same hardware drivers. Therefore, based on the documented criteria, this patch perfectly fits the definition of "unreachable code paths in virtualized environments," and it is safe to assign `WorthFuzzing=false`.

66/2 2026/08/10 22:40 tool set-results
0m Args: 
{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the AF_XDP TX metadata implementation to check for the XDP_TX_METADATA flag in the descriptor options before returning the metadata pointer. It updates the xsk_buff_get_metadata and xp_raw_get_ctx helpers and their callers. However, AF_XDP TX metadata and zero-copy are only supported by a few specific hardware drivers: igc, mlx5, stmmac, and idpf. None of these drivers are virtual, nor are they emulated in standard QEMU environments used by syzkaller. The veth and virtio_net drivers, which are reachable in virtualized environments, do not support AF_XDP TX metadata and do not call the modified functions. Therefore, the modified code paths are impossible to reach in virtualized environments.",
  "WorthFuzzing": false
}

Results: 
{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the AF_XDP TX metadata implementation to check for the XDP_TX_METADATA flag in the descriptor options before returning the metadata pointer. It updates the xsk_buff_get_metadata and xp_raw_get_ctx helpers and their callers. However, AF_XDP TX metadata and zero-copy are only supported by a few specific hardware drivers: igc, mlx5, stmmac, and idpf. None of these drivers are virtual, nor are they emulated in standard QEMU environments used by syzkaller. The veth and virtio_net drivers, which are reachable in virtualized environments, do not support AF_XDP TX metadata and do not call the modified functions. Therefore, the modified code paths are impossible to reach in virtualized environments.",
  "WorthFuzzing": false
}
67/1 2026/08/10 22:40 action If
0m Args: 
{
  "WorthFuzzing": false
}

Results: 
null
LLM Calls Summary:
Total Calls Total Tokens Avg Tokens Total Duration (Seconds) Avg Duration (Seconds)
Tool Calls Summary:
Total Calls Total Duration (Seconds) Avg Duration (Seconds)