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

[Larysa Zaremba <larysa.zaremba@intel.com>]

On Thu, Jul 23, 2026 at 08:39:47PM -0700, Joshua Washington wrote:
> 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(-)
> >

[...]

> 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.

Yes, given how gve_set_netdev_xdp_features() looks, this does seem like a false 
positive. Patch looks good to me.

Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>