Netdev List
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: amaan.cheval@gmail.com
Cc: netdev@vger.kernel.org, joshwash@google.com,
	hramamurthy@google.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, bcf@google.com, jordanrhee@google.com,
	przemyslaw.kitszel@intel.com, pkaligineedi@google.com,
	maolson@google.com, csully@google.com, willemb@google.com,
	yangchun@google.com, npl@google.com, awogbemila@google.com,
	shailend@google.com, nktgrg@google.com, maxyuan@google.com,
	bpf@vger.kernel.org, john.fastabend@gmail.com, hawk@kernel.org,
	sdf@fomichev.me, daniel@iogearbox.net, ast@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net v3] gve: leave refcount headroom in the RX page bias
Date: Wed, 04 Nov 2026 21:09:05 +0000	[thread overview]
Message-ID: <179382654505.488856.2284543045939069308@kernel.org> (raw)
In-Reply-To: <20261103090651.35399-1-amaan.cheval@gmail.com>

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

Critical: 1 · High: 0 · Medium: 0 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Critical] This patch refills the bias only after
  gve_dec_pagecnt_bias() reaches 0, and it lowers the per-page bias from…

--

gve: leave refcount headroom in the RX page bias

This patch lowers the gve RX page refcount bias from INT_MAX to USHRT_MAX
and stores it in a u16. This leaves page_count() room for references the
stack takes with get_page(), such as splice() and tee(). When the bias
reaches 0, it is refilled with a fixed batch of GVE_PAGECNT_BIAS.

Link: https://github.com/amaanc/kernel-bias

> diff --git a/drivers/net/ethernet/google/gve/gve_utils.c b/drivers/net/ethernet/google/gve/gve_utils.c
> index caed38cd5f2b3..cb6fba3122d5b 100644
> --- a/drivers/net/ethernet/google/gve/gve_utils.c
> +++ b/drivers/net/ethernet/google/gve/gve_utils.c
> @@ -93,15 +93,9 @@ void gve_dec_pagecnt_bias(struct gve_rx_slot_page_info *page_info)
>  {
>  	page_info->pagecnt_bias--;
>  	if (page_info->pagecnt_bias == 0) {
> -		int pagecount = page_count(page_info->page);
> -
> -		/* If we have run out of bias - set it back up to INT_MAX
> -		 * minus the existing refs.
> -		 */
> -		page_info->pagecnt_bias = INT_MAX - pagecount;
> -
> -		/* Set pagecount back up to max. */
> -		page_ref_add(page_info->page, INT_MAX - pagecount);
> +		/* Out of bias: take another batch of references. */
> +		page_info->pagecnt_bias = GVE_PAGECNT_BIAS;
> +		page_ref_add(page_info->page, GVE_PAGECNT_BIAS);
>  	}
>  }

[Severity: Critical]

Can this free a DQO-QPL RX page that is still registered with the device?

Because the refill happens only at 0, the 1 -> 0 transition hands the
driver's last reference to the consumer. With INT_MAX a page needed about
2^31 handoffs to get there. With GVE_PAGECNT_BIAS it happens every 65534
handoffs.

On DQO-QPL, gve_xdp_done_dqo() redirects the buffer before it touches the
bias:

	case XDP_REDIRECT:
		err = xdp_do_redirect(priv->dev, xdp, xprog);
		if (unlikely(err))
			goto err;
		gve_reuse_buffer(rx, buf_state);

gve_reg_xdp_info() registers QPL rings as MEM_TYPE_PAGE_SHARED. If the
redirect target is an AF_XDP socket in copy mode, the page is released
synchronously:

xdp_do_redirect()
  xsk_rcv()
    xdp_return_buff()
      __xdp_return()
        page_frag_free()
          put_page_testzero()
          free_frozen_pages()

Suppose the page is at pagecnt_bias == 1 and page_count == 1. That is the
normal recyclable state once all earlier consumers have released their
references. The QPL page then goes back to the buddy allocator while it is
still DMA mapped, registered in the QPL and owned by the buf_state.

After that, gve_reuse_buffer()->gve_dec_pagecnt_bias() calls
page_ref_add(page, GVE_PAGECNT_BIAS) on the freed page.
gve_try_recycle_buf() then sees page_count - bias == 0 and posts the page
back to the NIC. Could the device then DMA packet data into memory that
has already been handed to another user?

The v3 notes say XDP on DQO-QPL "will be blocked explicitly in a separate
patch". In this tree, gve_xdp(), gve_verify_xdp_configuration() and
gve_set_xdp() do not check queue_format.

gve_set_netdev_xdp_features() sets xdp_features = 0 for DQO-QPL, but
nothing on the attach path enforces it. xp_assign_dev() also falls back to
copy mode when NETDEV_XDP_ACT_XSK is missing.

That note is below the --- line, so it will not be in the applied commit.
The patch is also tagged for stable without naming the prerequisite.

The commit message also says:

  Use USHRT_MAX in a u16, as igb, igc, ixgbe, i40e and hns3 do

Those drivers refill at bias == 1, so they always keep a reference. For
example, igb_can_reuse_rx_page() does:

	if (unlikely(pagecnt_bias == 1)) {
		page_ref_add(page, USHRT_MAX - 1);
		rx_buffer->pagecnt_bias = USHRT_MAX;
	}

Would it be safer to refill at 1 here, as v2 did, so the driver never
gives up its last reference on a QPL page?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261103090651.35399-1-amaan.cheval%40gmail.com

      parent reply	other threads:[~2026-11-04 21:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  9:06 [PATCH net v3] gve: leave refcount headroom in the RX page bias Amaan Cheval
2026-11-04 15:46 ` Maciej Fijalkowski
2026-11-04 21:09 ` netdev-bot+sashiko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179382654505.488856.2284543045939069308@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=amaan.cheval@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=ast@kernel.org \
    --cc=awogbemila@google.com \
    --cc=bcf@google.com \
    --cc=bpf@vger.kernel.org \
    --cc=csully@google.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=hawk@kernel.org \
    --cc=hramamurthy@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jordanrhee@google.com \
    --cc=joshwash@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maolson@google.com \
    --cc=maxyuan@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=nktgrg@google.com \
    --cc=npl@google.com \
    --cc=pabeni@redhat.com \
    --cc=pkaligineedi@google.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sdf@fomichev.me \
    --cc=shailend@google.com \
    --cc=stable@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=yangchun@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox