linux.git/drivers/virtio, branch master

virtio_ring: fix infinite loop in virtnet_poll_cleantx when device is broken

2026-08-19T10:38:47+00:00

virtnet_poll_cleantx() contains a do-while loop that cleans up
transmitted TX buffers and calls virtqueue_enable_cb_delayed() to check
whether more buffers need processing. When the virtio backend stops
responding during guest reboot, used->idx is never updated, so
virtqueue_enable_cb_delayed() always returns false and the loop never
terminates. Then it will block reboot process, and the guest will hang.

The problem occurs during guest reboot under network traffic:

  1. kernel_restart() -> device_shutdown() traverses the device list
  2. virtio_dev_shutdown() calls virtio_break_device() which sets
     vq->broken = true
  3. virtio_dev_shutdown() then calls virtio_synchronize_cbs() to wait
     for in-flight callbacks to complete
  4. A virtio interrupt fires, softirq is deferred to ksoftirqd which
     calls net_rx_action() -> virtnet_poll() -> virtnet_poll_cleantx()
  5. virtnet_poll_cleantx() enters the do-while loop and never exits
     because the QEMU backend has stopped updating used->idx, despite
     vq->broken having been set to true in step 2.

Since the loop runs inside ksoftirqd (a SCHED_OTHER kthread), it is
visible to the scheduler and does not trigger a hard lockup. However,
the kthread never leaves the loop, so RCU detects it as a CPU stall
and reports it periodically. Meanwhile, the reboot process remains
blocked in device_shutdown() because virtio_dev_shutdown() cannot
complete its synchronization step, and the guest hangs permanently.

This can be reproduced on a guest with a virtio-net device: run iperf3
traffic in the guest, then trigger reboot. The reboot occasionally hangs
permanently with RCU stall on ksoftirqd.

Observed on ARM64 KVM guest:

  CPU#1 RCU stall (ksoftirqd/1), repeated periodically:
    virtqueue_enable_cb_delayed_split <- virtnet_poll <- __napi_poll <-
    net_rx_action <- handle_softirqs <- run_ksoftirqd <-
    smpboot_thread_fn <- kthread

Fix by adding a vq->broken check in virtqueue_enable_cb_delayed(), so
that the loop exits immediately when the device is broken, allowing
the device shutdown to proceed.

Signed-off-by: Jinqian Yang 
Reviewed-by: Xuan Zhuo 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260716115940.394832-1-yangjinqian1@huawei.com>

virtio_mem: fix typo in comment

2026-08-19T10:38:47+00:00

Correct "actipn" to "action".

Signed-off-by: xiongweimin 
Reviewed-by: Parav Pandit 
Acked-by: David Hildenbrand (Arm) 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260714032417.201353-1-xiongwm2026@163.com>

virtio: fix article before virtio in dma-buf comment

2026-08-19T10:38:47+00:00

Use "a virtio" rather than "an virtio".

Signed-off-by: xiongweimin 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260714024513.188571-1-15927021679@163.com>

virtio: rtc: time out alarm requests

2026-08-19T10:38:47+00:00

RTC class operations run with rtc_device.ops_lock held. The virtio RTC
alarm requests currently wait without a timeout for the device to return
their requestq buffers.

On surprise removal, virtio-pci marks the virtqueues broken before
unregistering the virtio device. If an alarm request is waiting when the
device stops responding, viortc_remove() blocks in viortc_class_stop()
while trying to acquire ops_lock. The request cannot complete and device
removal hangs until the waiting task is signalled.

Use the same 60-second timeout as clock read requests for alarm reads,
alarm programming, and alarm interrupt enable requests. The existing
message reference counting keeps a timed-out request alive until a late
response or device teardown.

Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: GuoHan Zhao 
Reviewed-by: Peter Hilber 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260714024352.71307-1-zhaoguohan@kylinos.cn>

virtio_pci: fix wrong queue index for admin vq in intx path

2026-08-19T10:38:45+00:00

In vp_find_vqs_intx(), the admin vq was set up using the local
queue_idx counter instead of avq->vq_index (the actual queue index
obtained from the device). This differs from vp_find_vqs_msix() which
correctly uses avq->vq_index. Using the wrong index causes the admin
virtqueue to be mapped to an incorrect hardware queue.

Fix it by using avq->vq_index consistent with the msix path.

Fixes: af22bbe1f4a5 ("virtio: create admin queues alongside other virtqueues")
Signed-off-by: Li RongQing 
Message-ID: <20260629033538.2476-1-lirongqing@baidu.com>
Signed-off-by: Michael S. Tsirkin

virtio_mem: fix hardcoded 'vm' variable in bbm iteration macros

2026-08-19T10:38:45+00:00

virtio_mem_bbm_for_each_bb() and virtio_mem_bbm_for_each_bb_rev()
accept a '_vm' parameter to allow callers to pass any variable name
referring to the virtio_mem instance. However, the 'for' loop
initializer and part of the loop condition use the bare name 'vm'
instead of the macro parameter '_vm'.

Fix by replacing all bare 'vm->' references inside the macros with
the '_vm' parameter, and wrap in parentheses following kernel macro
conventions.

Signed-off-by: Li RongQing 
Acked-by: David Hildenbrand (Arm) 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260630045952.2188-1-lirongqing@baidu.com>

virtio_balloon: warn on failed buffer add in stats_handle_request()

2026-08-19T10:38:44+00:00

Like tell_host(), stats_handle_request() ignores the return value of
virtqueue_add_outbuf() and kicks the queue regardless. The same "we
should always be able to add one buffer to an empty queue" assumption
does not hold once the virtqueue has been broken (e.g. on device
shutdown), where the add fails with -EIO. Unlike tell_host() it does
not wait_event() afterwards so it cannot hang, but it still kicks a
queue with nothing queued.

Warn and bail out on failure, mirroring tell_host() and
virtballoon_free_page_report().

Suggested-by: David Hildenbrand 
Signed-off-by: Denis V. Lunev 
Reviewed-by: David Hildenbrand (Arm) 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260624154001.2733242-1-den@openvz.org>

virtio_balloon: warn on failed buffer add in tell_host()

2026-08-19T10:38:44+00:00

tell_host() ignores the return value of virtqueue_add_outbuf() and goes
on to kick the queue and wait_event() for the host's ack. The comment
claims "We should always be able to add one buffer to an empty queue",
but that does not hold once the virtqueue has been broken (e.g. on
device shutdown): the add then fails with -EIO and the following
wait_event() would block forever on a buffer the host can never return.

Warn and bail out on failure, mirroring virtballoon_free_page_report().

Suggested-by: David Hildenbrand 
Signed-off-by: Denis V. Lunev 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260624140846.2616797-5-den@openvz.org>

virtio_balloon: quiesce balloon work before device shutdown

2026-08-19T10:38:44+00:00

Commit 8bd2fa086a04 ("virtio: break and reset virtio devices on
device_shutdown()") added a generic virtio bus .shutdown handler that
breaks and resets every virtio device during device_shutdown(), i.e. on
reboot and kexec.

virtio_balloon provides no .shutdown of its own, so that generic path
runs while the balloon's asynchronous work is still armed. Once the
device has been broken, virtqueue_add_inbuf() in
virtballoon_free_page_report() returns -EIO and trips its
WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an
ordinary reboot, for example a kexec based upgrade, into a fatal panic
in the middle of device_shutdown(), so the machine never reaches the
new kernel.

Relaxing that single WARN_ON_ONCE() would only hide the symptom: the
inflate/deflate and OOM paths do not warn, they call
wait_event(vb->acked, ...) and would instead block forever on a broken
queue that can no longer complete. The device has to be quiesced, not
just kept quiet.

Add a .shutdown handler that quiesces the balloon via the shared
virtballoon_quiesce() helper while the device is still alive, and only
then breaks and resets it via virtio_device_shutdown(). Unlike
virtballoon_remove() the balloon workqueue is not destroyed, as shutdown
does not free the device and cancel_work_sync() together with stop_update
already prevent any further work from being queued.

Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on device_shutdown()")
Signed-off-by: Denis V. Lunev 
Reviewed-by: David Hildenbrand (Arm) 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260624140846.2616797-4-den@openvz.org>

virtio_balloon: factor out virtballoon_quiesce()

2026-08-19T10:38:44+00:00

virtballoon_remove() stops all of the balloon's asynchronous work (the
free page reporting worker, the inflate/deflate and stats workers, the
OOM notifier and the free page shrinker) before tearing the device
down. A following change needs the same teardown from a .shutdown
handler, so move it into a virtballoon_quiesce() helper.

No functional change.

Signed-off-by: Denis V. Lunev 
Reviewed-by: David Hildenbrand (Arm) 
Signed-off-by: Michael S. Tsirkin 
Message-ID: <20260624140846.2616797-3-den@openvz.org>