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@xxxxxxxxxx> 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@xxxxxxxxxx>
> Reviewed-by: Jordan Rhee <jordanrhee@xxxxxxxxxx>
> Signed-off-by: Joshua Washington <joshwash@xxxxxxxxxx>
> ---
> 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.