[PATCH net-next v3 0/2] XDP metadata support for DQ RDA

[PATCH net-next v3 0/2] XDP metadata support for DQ RDA

[Joshua Washington]

This small series enables XDP metadata support in DQ RDA mode. While
space is reserved in the headroom for metadata and the DQ queue format
supports the xmo_rx_timestamp metadata operation, support for adjusting
the metadata and passing metadata along to SKBs was not actually
implemented.

v3:
  - Make use of xdp_build_skb methods to implicitly pass on metadata
    when constructing SKBs from XDP buffs.
  - v2: https://lore.kernel.org/netdev/20260318192450.3400774-1-joshwash@google.com/
v2:
  - Fix referenced commit hash
  - v1: https://lore.kernel.org/netdev/20260316230434.1398828-1-joshwash@google.com/

Joshua Washington (2):
  gve: use xdp_build_skb methods for XDP_PASS case
  gve: add XDP metadata support for DQ RDA

 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

-- 
2.55.0.229.g6434b31f56-goog

[PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[Joshua Washington]

Newer common methods have been introduced to construct SKBs in the
event of XDP_PASS because many drivers replicated very similar
functionality. Update GVE to use these common methods for copy mode and
zero-copy mode.

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
v3:
  - Newly introduced. Ensures that XDP metadata is passed onto SKB in
    XDP_PASS case.
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 02cba280d81a..907a0c15bf30 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -736,8 +736,7 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 	}
 
 	/* Copy the data to skb */
-	rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi,
-					    xdp->data, buf_len);
+	rx->ctx.skb_head = xdp_build_skb_from_zc(xdp);
 	if (unlikely(!rx->ctx.skb_head)) {
 		xsk_buff_free(xdp);
 		gve_free_buf_state(rx, buf_state);
@@ -745,8 +744,6 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 	}
 	rx->ctx.skb_tail = rx->ctx.skb_head;
 
-	/* Free XSK buffer and Buffer state */
-	xsk_buff_free(xdp);
 	gve_free_buf_state(rx, buf_state);
 
 	/* Update Stats */
@@ -899,9 +896,17 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 			return 0;
 		}
 
+		rx->ctx.skb_head = xdp_build_skb_from_buff(&gve_xdp.xdp);
+		if (unlikely(!rx->ctx.skb_head))
+			goto error;
+		rx->ctx.skb_tail = rx->ctx.skb_head;
+
+		gve_reuse_buffer(rx, buf_state);
+
 		u64_stats_update_begin(&rx->statss);
 		rx->xdp_actions[XDP_PASS]++;
 		u64_stats_update_end(&rx->statss);
+		return 0;
 	}
 
 	if (eop && buf_len <= priv->rx_copybreak &&
-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Early return for `XDP_PASS` packets bypasses QPL copy-on-demand check, leading to RX ring starvation.

Pre-existing issues:
- [High] Unconditional SKB overwriting in `gve_rx_xsk_dqo` for multi-fragment AF_XDP packets causes memory leaks and packet truncation.
- [High] Missing state tracking for dropped fragments in multi-descriptor DQO packets causes subsequent fragments to be treated as new packets.
--

--- Patch [1]: [PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case ---
commit 3d3251679ac8ebd21a150064685ec273582e184c
Author: Joshua Washington <joshwash@google.com>

gve: use xdp_build_skb methods for XDP_PASS case

Newer common methods have been introduced to construct SKBs in the
event of XDP_PASS because many drivers replicated very similar
functionality. Update GVE to use these common methods for copy mode and
zero-copy mode.

> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 02cba280d81a8..907a0c15bf302 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -736,8 +736,7 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>  	}
>  
>  	/* Copy the data to skb */
> -	rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi,
> -					    xdp->data, buf_len);
> +	rx->ctx.skb_head = xdp_build_skb_from_zc(xdp);

[Severity: High]
This isn't a bug introduced by this patch, but does this unconditionally
overwrite the SKB head on every fragment for multi-fragment packets?

If an AF_XDP enabled interface receives a jumbo frame (e.g., 9000 bytes),
the hardware splits the packet across multiple RX descriptors. For each
descriptor, gve_rx_xsk_dqo() allocates a new SKB here and assigns it to
rx->ctx.skb_head.

Since this ignores whether rx->ctx.skb_head is already populated from previous
fragments, does it leak the SKBs of prior fragments and truncate the delivered
packet?

[ ... ]

> @@ -894,14 +891,22 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>  		buf_state->page_info.pad += gve_xdp.xdp.data - old_data;
>  		buf_len = gve_xdp.xdp.data_end - gve_xdp.xdp.data;
>  		if (xdp_act != XDP_PASS) {
>  			gve_xdp_done_dqo(priv, rx, &gve_xdp.xdp, xprog, xdp_act,
>  					 buf_state);
>  			return 0;
>  		}

[Severity: High]
This is a pre-existing issue, but if the first fragment of a multi-descriptor
packet is dropped (e.g. XDP_DROP), does the driver fail to track that the rest
of the packet must be dropped?

When the next descriptor containing the middle of the payload arrives,
rx->ctx.skb_head will be NULL. Will the driver incorrectly treat this fragment
as a new Ethernet frame and run the XDP program on arbitrary payload data?

>  
> +		rx->ctx.skb_head = xdp_build_skb_from_buff(&gve_xdp.xdp);
> +		if (unlikely(!rx->ctx.skb_head))
> +			goto error;
> +		rx->ctx.skb_tail = rx->ctx.skb_head;
> +
> +		gve_reuse_buffer(rx, buf_state);
> +
>  		u64_stats_update_begin(&rx->statss);
>  		rx->xdp_actions[XDP_PASS]++;
>  		u64_stats_update_end(&rx->statss);
> +		return 0;

[Severity: High]
Does returning 0 here bypass the copy-on-demand safety check for XDP_PASS
packets?

The gve_rx_should_trigger_copy_ondemand() check at the end of gve_rx_dqo()
appears to be skipped. By bypassing this check, could the networking stack
hold onto the QPL pages indefinitely?

This might drive used_buf_states_cnt to num_buf_states, exhausting the buffer
pool and preventing new RX buffers from being posted to hardware, ultimately
starving the RX ring.

>  	}
>  
>  	if (eop && buf_len <= priv->rx_copybreak &&

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722221634.186886-1-joshwash@google.com?part=1

Re: [PATCH net-next v3 1/2] gve: use xdp_build_skb methods for XDP_PASS case

[Joshua Washington]

On Wed, Jul 22, 2026 at 3:16 PM Joshua Washington <joshwash@google.com> wrote:
>
> Newer common methods have been introduced to construct SKBs in the
> event of XDP_PASS because many drivers replicated very similar
> functionality. Update GVE to use these common methods for copy mode and
> zero-copy mode.
>
> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
> Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Joshua Washington <joshwash@google.com>
> ---
> v3:
>   - Newly introduced. Ensures that XDP metadata is passed onto SKB in
>     XDP_PASS case.
> ---
>  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 02cba280d81a..907a0c15bf30 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -736,8 +736,7 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>         }
>
>         /* Copy the data to skb */
> -       rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi,
> -                                           xdp->data, buf_len);
> +       rx->ctx.skb_head = xdp_build_skb_from_zc(xdp);

Sashiko says:
---
[Severity: High]
This isn't a bug introduced by this patch, but does this unconditionally
overwrite the SKB head on every fragment for multi-fragment packets?

If an AF_XDP enabled interface receives a jumbo frame (e.g., 9000 bytes),
the hardware splits the packet across multiple RX descriptors. For each
descriptor, gve_rx_xsk_dqo() allocates a new SKB here and assigns it to
rx->ctx.skb_head.

Since this ignores whether rx->ctx.skb_head is already populated from previous
fragments, does it leak the SKBs of prior fragments and truncate the delivered
packet?
---

Multi-buffer XDP is not supported in GVE DQ.

>         if (unlikely(!rx->ctx.skb_head)) {
>                 xsk_buff_free(xdp);
>                 gve_free_buf_state(rx, buf_state);
> @@ -745,8 +744,6 @@ static int gve_rx_xsk_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>         }
>         rx->ctx.skb_tail = rx->ctx.skb_head;
>
> -       /* Free XSK buffer and Buffer state */
> -       xsk_buff_free(xdp);
>         gve_free_buf_state(rx, buf_state);
>
>         /* Update Stats */
> @@ -899,9 +896,17 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>                         return 0;
>                 }
>
> +               rx->ctx.skb_head = xdp_build_skb_from_buff(&gve_xdp.xdp);
> +               if (unlikely(!rx->ctx.skb_head))
> +                       goto error;
> +               rx->ctx.skb_tail = rx->ctx.skb_head;
> +
> +               gve_reuse_buffer(rx, buf_state);
> +
>                 u64_stats_update_begin(&rx->statss);
>                 rx->xdp_actions[XDP_PASS]++;
>                 u64_stats_update_end(&rx->statss);
> +               return 0;

Sashiko says:
---
[Severity: High]
Does returning 0 here bypass the copy-on-demand safety check for XDP_PASS
packets?

The gve_rx_should_trigger_copy_ondemand() check at the end of gve_rx_dqo()
appears to be skipped. By bypassing this check, could the networking stack
hold onto the QPL pages indefinitely?

This might drive used_buf_states_cnt to num_buf_states, exhausting the buffer
pool and preventing new RX buffers from being posted to hardware, ultimately
starving the RX ring.
---

DQ QPL doesn't have XDP support, so QPL pages are not in use.

>         }
>
>         if (eop && buf_len <= priv->rx_copybreak &&
> --
> 2.55.0.229.g6434b31f56-goog
>


Sashiko says:
---
> @@ -894,14 +891,22 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>               buf_state->page_info.pad += gve_xdp.xdp.data - old_data;
>               buf_len = gve_xdp.xdp.data_end - gve_xdp.xdp.data;
>               if (xdp_act != XDP_PASS) {
>                       gve_xdp_done_dqo(priv, rx, &gve_xdp.xdp, xprog, xdp_act,
>                                        buf_state);
>                       return 0;
>               }

[Severity: High]
This is a pre-existing issue, but if the first fragment of a multi-descriptor
packet is dropped (e.g. XDP_DROP), does the driver fail to track that the rest
of the packet must be dropped?

When the next descriptor containing the middle of the payload arrives,
rx->ctx.skb_head will be NULL. Will the driver incorrectly treat this fragment
as a new Ethernet frame and run the XDP program on arbitrary payload data?
---

Again, GVE DQ doesn't support multi-buffer XDP. This will be addressed
when support is added.

-- 

Joshua Washington | Software Engineer | joshwash@google.com | (414) 366-4423

[PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA

[Joshua Washington]

Commit 1b42e07af1ee ("gve: Add Rx HWTS metadata to AF_XDP ZC mode")
exposes support for the XDP RX timestamping metadata operation in the DQ
RDA mode. While the operation works on its own, the intent was to enable
XDP metadata support for the queue format as a whole along with it.
Currently bpf_xdp_adjust_meta fails because meta_valid is set to false.
This change updates xdp_buff preparation to set meta_valid to true, so
metadata can be fully used by XDP programs.

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
v3:
  - bfp -> bpf
v2:
  - Fix referenced commit in description
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 907a0c15bf30..329a2585489b 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -882,7 +882,7 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 				 buf_state->page_info.page_address +
 				 buf_state->page_info.page_offset,
 				 buf_state->page_info.pad,
-				 buf_len, false);
+				 buf_len, true);
 		gve_xdp.gve = priv;
 		gve_xdp.compl_desc = compl_desc;
 
-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] In GVE DQO QPL mode with XDP enabled, `buf_state->page_info.pad` accumulates XDP head adjustments and drifts unbounded, leading to out-of-bounds hardware DMA.
- [High] Missing fragment drop tracking for multi-descriptor packets in the DQO RX path causes subsequent fragments of a dropped packet to be treated as new packets, bypassing XDP and network security filters.
--

--- Patch [2]: [PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA ---
commit 7fa79d59c32cc58b133c8b5735d2691860bcdca2
Author: Joshua Washington <joshwash@google.com>

gve: add XDP metadata support for DQ RDA

This commit updates xdp_prepare_buff to set meta_valid to true in
gve_rx_dqo. This enables XDP programs to use metadata in the DQ RDA mode.

> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
[ ... ]
>  	/* Append to current skb if one exists. */
>  	if (rx->ctx.skb_head) {
>  		if (unlikely(gve_rx_append_frags(napi, buf_state, buf_len, rx,
>  						 priv)) != 0) {
>  			goto error;
>  		}
>  		return 0;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but I have a question about
fragment drop tracking for multi-descriptor packets in this DQO RX path.

If the first fragment of a multi-descriptor packet is dropped (e.g., by XDP),
rx->ctx.skb_head remains NULL. Unlike the GQI path which tracks
rx->ctx.drop_pkt, the DQO path does not seem to track dropped state.

Will subsequent fragments of that dropped packet see rx->ctx.skb_head == NULL,
bypass this append logic, and fall through to the XDP block below, treating
the fragment as a new packet?

>  
>  	if (xprog) {
>  		struct gve_xdp_buff gve_xdp;
>  		void *old_data;
>  		int xdp_act;
>  
>  		xdp_init_buff(&gve_xdp.xdp, buf_state->page_info.buf_size,
>  			      &rx->xdp_rxq);
>  		xdp_prepare_buff(&gve_xdp.xdp,
>  				 buf_state->page_info.page_address +
>  				 buf_state->page_info.page_offset,
>  				 buf_state->page_info.pad,
> -				 buf_len, false);
> +				 buf_len, true);
>  		gve_xdp.gve = priv;
>  		gve_xdp.compl_desc = compl_desc;
>  
>  		old_data = gve_xdp.xdp.data;
>  		xdp_act = bpf_prog_run_xdp(xprog, &gve_xdp.xdp);
>  		buf_state->page_info.pad += gve_xdp.xdp.data - old_data;

[Severity: High]
This is a pre-existing issue, but does accumulating the XDP head adjustment
into buf_state->page_info.pad lead to out-of-bounds hardware DMA?

When XDP programs adjust the packet head, the difference is accumulated into
the pad. When the buffer is recycled, it appears the pad is never reset to
the default headroom. 

Could this cause subsequent reuses of the buffer to continue accumulating
the offset and eventually calculate an out-of-bounds DMA address in
gve_alloc_buffer():

drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c:gve_alloc_buffer() {
    ...
    desc->buf_addr = cpu_to_le64(buf_state->addr +
                                 buf_state->page_info.page_offset +
                                 buf_state->page_info.pad);
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722221634.186886-1-joshwash@google.com?part=2

Re: [PATCH net-next v3 2/2] gve: add XDP metadata support for DQ RDA

[Joshua Washington]

On Wed, Jul 22, 2026 at 3:16 PM Joshua Washington <joshwash@google.com> wrote:
>
> Commit 1b42e07af1ee ("gve: Add Rx HWTS metadata to AF_XDP ZC mode")
> exposes support for the XDP RX timestamping metadata operation in the DQ
> RDA mode. While the operation works on its own, the intent was to enable
> XDP metadata support for the queue format as a whole along with it.
> Currently bpf_xdp_adjust_meta fails because meta_valid is set to false.
> This change updates xdp_buff preparation to set meta_valid to true, so
> metadata can be fully used by XDP programs.
>
> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
> Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Joshua Washington <joshwash@google.com>
> ---
> v3:
>   - bfp -> bpf
> v2:
>   - Fix referenced commit in description
> ---
>  drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> index 907a0c15bf30..329a2585489b 100644
> --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> @@ -882,7 +882,7 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
>                                  buf_state->page_info.page_address +
>                                  buf_state->page_info.page_offset,
>                                  buf_state->page_info.pad,
> -                                buf_len, false);
> +                                buf_len, true);
>                 gve_xdp.gve = priv;
>                 gve_xdp.compl_desc = compl_desc;
>
> --
> 2.55.0.229.g6434b31f56-goog
>

Sashiko says:
---
>       if (xprog) {
>               struct gve_xdp_buff gve_xdp;
>               void *old_data;
>               int xdp_act;
>
>               xdp_init_buff(&gve_xdp.xdp, buf_state->page_info.buf_size,
>                             &rx->xdp_rxq);
>               xdp_prepare_buff(&gve_xdp.xdp,
>                                buf_state->page_info.page_address +
>                                buf_state->page_info.page_offset,
>                                buf_state->page_info.pad,
> -                              buf_len, false);
> +                              buf_len, true);
>               gve_xdp.gve = priv;
>               gve_xdp.compl_desc = compl_desc;
>
>               old_data = gve_xdp.xdp.data;
>               xdp_act = bpf_prog_run_xdp(xprog, &gve_xdp.xdp);
>               buf_state->page_info.pad += gve_xdp.xdp.data - old_data;

[Severity: High]
This is a pre-existing issue, but does accumulating the XDP head adjustment
into buf_state->page_info.pad lead to out-of-bounds hardware DMA?

When XDP programs adjust the packet head, the difference is accumulated into
the pad. When the buffer is recycled, it appears the pad is never reset to
the default headroom.

Could this cause subsequent reuses of the buffer to continue accumulating
the offset and eventually calculate an out-of-bounds DMA address in
gve_alloc_buffer():

drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c:gve_alloc_buffer() {
    ...
    desc->buf_addr = cpu_to_le64(buf_state->addr +
                                 buf_state->page_info.page_offset +
                                 buf_state->page_info.pad);
    ...
}
---

This is not acutally a concern becasue gve_alloc_buffer() always
resets the the pad based on the page pool's offset parameter. This is
something that would need to be accounted for in the case of DQ QPL,
which does not yet support XDP.