[PATCH net v3 0/3] gve: various XDP fixes

[PATCH net v3 0/3] gve: various XDP fixes

[Joshua Washington]

This patch series consists of a number of small XDP-related fixes.

These changes are split off from
https://lore.kernel.org/netdev/20260922194533.631387-1-joshwash@google.com/
in an effort to prevent blocking relatively simple fixes on more complex
fixes that will need more feedback to merge.

A summary of the changes:
1) fix an issue where XSK buffers that have not been processed are
   leaked when disabling XSK pools
2) fix an XSK buffer leak when an RX error descriptor comes back from
   the hardware
3) fix a deadlock introduced by attempting to acquire the netdev lock
   after it has already been acquired

---
v3:
- Remove the more controversial fixes so that simpler fixes, (the
  deadlock fix in particular), are not blocked.
- v2: https://lore.kernel.org/netdev/20260922194533.631387-1-joshwash@google.com/

v2:
- introduce 3 new patches (7, 8, 9) based on Sashiko feedback
- corrected stat counting for packets according work_done behavioral
  change (patch 1)
- v1: https://lore.kernel.org/netdev/20260814234845.773189-1-joshwash@google.com/

Joshua Washington (3):
  gve: fix XSK buffer leak when rings are stopped
  gve: fix XSK buffer leak on error descriptor
  gve: fix napi_disable deadlock when attempting to disable XSK pools

 drivers/net/ethernet/google/gve/gve_main.c   |  8 ++++----
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 13 ++++++++++++-
 2 files changed, 16 insertions(+), 5 deletions(-)

-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH net v3 1/3] gve: fix XSK buffer leak when rings are stopped

[Joshua Washington]

GVE does not free XSK buffers when resetting ring state as a part of
stopping queues. This causes all XSK buffers which are posted to the
NIC to be leaked.

Free XSK buffers attached to an allocated buf_state when stopping rings.

Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy")
Cc: stable@vger.kernel.org
Reviewed-by: Tim Hostetler <thostet@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 5cf242b28557..a2c4a08ce68d 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -113,6 +113,12 @@ static void gve_rx_reset_ring_dqo(struct gve_priv *priv, int idx)
 				gve_free_to_page_pool(rx, bs, false);
 			else
 				gve_free_qpl_page_dqo(bs);
+
+			if (gve_buf_state_is_allocated(rx, bs) &&
+			    bs->xsk_buff) {
+				xsk_buff_free(bs->xsk_buff);
+				bs->xsk_buff = NULL;
+			}
 		}
 	}
 
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH net v3 2/3] gve: fix XSK buffer leak on error descriptor

[Joshua Washington]

When the error bit is set in the RX completion descriptor, the buf_state
and its attached buffer should be freed. In the case of AF_XDP ZC, the
XSK buffer was not freed, leading to a leak.

Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy")
Cc: stable@vger.kernel.org
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Reviewed-by: Tim Hostetler <thostet@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 7 ++++++-
 1 file changed, 6 insertions(+), 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 a2c4a08ce68d..82ed5e48b00a 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -842,7 +842,12 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx,
 	}
 
 	if (unlikely(compl_desc->rx_error)) {
-		gve_free_buffer(rx, buf_state);
+		if (buf_state->xsk_buff) {
+			xsk_buff_free(buf_state->xsk_buff);
+			gve_free_buf_state(rx, buf_state);
+		} else {
+			gve_free_buffer(rx, buf_state);
+		}
 		return -EINVAL;
 	}
 
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH net v3 3/3] gve: fix napi_disable deadlock when attempting to disable XSK pools

[Joshua Washington]

When disabling XSK pools, GVE calls the unlocked versions of
napi_disable and napi_enable. However, the netdev lock has already been
acquired before ndo_bpf is called because GVE supports queue management
ops. Calling the unlocked versions of napi_disable/enable results in a
deadlock when attempting to disable XSK pools, as the thread attempts to
re-acquire a lock it already holds.

Update the NAPI calls to use the locked versions.

Fixes: 606048cbd834 ("net: designate XSK pool pointers in queues as "ops protected"")
Cc: stable@vger.kernel.org
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Joshua Washington <joshwash@google.com>
---
 drivers/net/ethernet/google/gve/gve_main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 9cc343a16271..a6c18e2431cc 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1708,17 +1708,17 @@ static int gve_xsk_pool_disable(struct net_device *dev,
 	}
 
 	napi_rx = &priv->ntfy_blocks[priv->rx[qid].ntfy_id].napi;
-	napi_disable(napi_rx); /* make sure current rx poll is done */
+	napi_disable_locked(napi_rx); /* make sure current rx poll is done */
 
 	tx_qid = gve_xdp_tx_queue_id(priv, qid);
 	napi_tx = &priv->ntfy_blocks[priv->tx[tx_qid].ntfy_id].napi;
-	napi_disable(napi_tx); /* make sure current tx poll is done */
+	napi_disable_locked(napi_tx); /* make sure current tx poll is done */
 
 	gve_unreg_xsk_pool(priv, qid);
 	smp_mb(); /* Make sure it is visible to the workers on datapath */
 
-	napi_enable(napi_rx);
-	napi_enable(napi_tx);
+	napi_enable_locked(napi_rx);
+	napi_enable_locked(napi_tx);
 	if (gve_is_gqi(priv)) {
 		if (gve_rx_work_pending(&priv->rx[qid]))
 			napi_schedule(napi_rx);
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

Re: [PATCH net v3 0/3] gve: various XDP fixes

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v3 0/3] gve: various XDP fixes

[Joshua Washington]

On Wed, Sep 30, 2026 at 2:54 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.

(1/3) gve: fix XSK buffer leak when rings are stopped

This issue was hit in production.

(2/3) gve: fix XSK buffer leak on error descriptor

This issue was caught by LLM

(3/3)  gve: fix napi_disable deadlock when attempting to disable XSK pools

This issue was found in production.


>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

(1/3) gve: fix XSK buffer leak when rings are stopped

This issue was actually triggered; symptoms included a buffer leak.
Reproduced by continually performing ip link up/down on an interface
while XSK traffic was flowing. Eventually, no more packets can pass
because all of the XSK buffers from the UMEM pool have been leaked.

(2/3) gve: fix XSK buffer leak on error descriptor

This issue is theoretical, as RX error packets are extremely rare in
my personal experience. But it is plain to see by static analysis that
the buffer will be leaked if an RX error is returned, due to the early
return in the driver. All other XSK-releated paths free the XSK buffer
in gve_rx_xsk_dqo().

(3/3)  gve: fix napi_disable deadlock when attempting to disable XSK pools

This one can be very easily reproduced by enabling an AF_XDP zero-copy
socket, and disabling it. The deadlock becomes more apparent when
attempting to enable a second AF_XDP zero-copy socket, as that
operation will stall waiting to get the netdev instance lock.

Snipped stacktrace from
https://github.com/GoogleCloudPlatform/compute-virtual-ethernet-linux/pull/96:

Workqueue: events xp_release_deferred
napi_disable+0x1d/0x50
gve_xsk_pool_disable+0xed/0x1d0 [gve]
gve_xdp+0x14a/0x1c0 [gve]
xp_disable_drv_zc+0x89/0xe0
xp_clear_dev+0x59/0xf0
xp_release_deferred+0x20/0x90

>
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.

All of these changes were tested on the GVE driver using the DQO RDA
queue format.

>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.



-- 

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