Re: [BUG] virtio_net: RX stall caused by masking callbacks after NAPI ownership release

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 11, 2026 at 09:36:10PM +0800, Congjie Zhou wrote:
> Hello,
> 
> I observed a persistent virtio-net RX stall on Linux 6.18.58 during a
> multi-threaded TCP receive workload. After the stall, the RX virtqueue
> contained unconsumed used entries, but its NAPI instance had no owner,
> the NAPI timer was inactive and virtqueue notifications were disabled.
> The receiving TCP threads remained blocked waiting for data.


Played with it a bit since. I think the below should do it?
Can you confirm?

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index dd2c41ef6fbe7..7bc7306231521 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -740,6 +740,8 @@ static bool virtqueue_napi_complete(struct napi_struct *napi,
 			return true;
 	} else {
 		virtqueue_disable_cb(vq);
+		if (!napi_is_deferred(napi) && !napi_is_scheduled(napi))
+			napi_schedule(napi);
 	}
 
 	return false;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c0ae442c4344b..2199750825d4f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -22,6 +22,7 @@
 #define _LINUX_NETDEVICE_H
 
 #include <linux/timer.h>
+#include <linux/hrtimer.h>
 #include <linux/bug.h>
 #include <linux/delay.h>
 #include <linux/atomic.h>
@@ -553,6 +554,21 @@ static inline bool napi_is_scheduled(struct napi_struct *n)
 	return test_bit(NAPI_STATE_SCHED, &n->state);
 }
 
+/**
+ * napi_is_deferred - test if the NAPI timer is armed and will schedule NAPI
+ * @n: NAPI context
+ *
+ * A true answer guarantees NAPI will be polled again without driver
+ * action.  A false answer is "best-effort": the timer can be armed
+ * right after the check.
+ *
+ * Return: True if timer is armed, False otherwise.
+ */
+static inline bool napi_is_deferred(struct napi_struct *n)
+{
+	return hrtimer_active(&n->timer);
+}
+
 bool napi_schedule_prep(struct napi_struct *n);
 
 /**