On Sat, Sep 05, 2026 at 05:20:56PM +0200, Karl Mehltretter wrote:
> A virtqueue callback can outlive virtio_reset_device() and race with a
> driver freeing the state it uses. The reset helper documents that no
> callbacks remain in progress, but that depends on the transport:
> virtio-pci waits in vp_reset(), while virtio-mmio does not.
>
> virtio_input has a related ordering problem: it unregisters the input
> device before resetting the virtio device, while an event callback may
> still be using the input device.
>
> Patch 1 moves the callback wait into the core, using the existing
> virtio_synchronize_cbs() operation. Patch 2 fixes the virtio_input teardown
> order. Patch 3 adds the missing synchronize_cbs hooks for UML, TmFIFO,
> remoteproc and virtio-vdpa. Remoteproc uses one SRCU domain per processor.
>
> The new hooks wait for callbacks already running. UML, TmFIFO and
> remoteproc still allow new callbacks after reset; fixing that is separate
> work. The event-virtqueue DMA mapping issue is also separate.
>
> Changes in v2:
> - Patch 1: move the wait into the core instead of fixing only MMIO, as
> Michael suggested. Remove the duplicate PCI wait, preserve its shutdown
> wait, and fix CCW callback locking. Drop the MMIO polling: reset polling
> for v3 and newer is already in fa8833c085b6 ("virtio-mmio: add support
> for transport version 3").
> - Patch 2: keep draining completed events when ready becomes false,
> instead of breaking out, so teardown does not truncate an input packet.
> - Patch 3 is new, at Michael's request.
You didn't send patch 3.
> I reran the 120-cycle unbind/rebind test in an arm64 KASAN guest with four
> vCPUs and a 5 ms busy delay per event. With patch 2 alone over virtio-mmio,
> reset returned with the callback still running in all 84 overlapping
> cycles. With the series, it waited in all 103. Over PCI with per-queue
> MSI-X, it waited in all 66, including runs with threadirqs. No KASAN or
> lockdep reports. These runs predate the per-rproc change, which leaves
> the tested MMIO and PCI paths unchanged. They confirmed the missing wait,
> but did not reproduce a use-after-free: with evdev attached,
> input_unregister_device() waits for an RCU grace period that the IRQ
> callback blocks.
>
> That version also passed QEMU input, rebind and shutdown checks on arm64
> MMIO and x86-64 PCI, including arm64 RT, KASAN and KCSAN builds, and x86
> UP/Tiny SRCU. A legacy INTx NIC was present for an additional x86
> shutdown check. The changed objects built with W=1 without warnings on
> arm64, x86-64, s390 and SMP UML. The per-rproc version built with W=1
> on arm64 KASAN and x86 Tiny SRCU, and passed six remoteproc callback and
> lifetime KUnit tests on each, using mock remoteproc devices.
>
> Link: https://lore.kernel.org/r/[email protected]
>
> Karl Mehltretter (3):
> virtio: synchronize callbacks during device reset
> virtio_input: stop callbacks before unregistering input device
> virtio: implement synchronize_cbs for remaining transports
>
> arch/um/drivers/virtio_uml.c | 10 ++++++++++
> drivers/platform/mellanox/mlxbf-tmfifo.c | 14 ++++++++++++++
> drivers/remoteproc/remoteproc_core.c | 10 ++++++++++
> drivers/remoteproc/remoteproc_virtio.c | 20 +++++++++++++++++---
> drivers/s390/virtio/virtio_ccw.c | 6 +-----
> drivers/virtio/virtio.c | 2 ++
> drivers/virtio/virtio_input.c | 8 ++++++--
> drivers/virtio/virtio_pci_legacy.c | 2 --
> drivers/virtio/virtio_pci_modern.c | 3 ---
> drivers/virtio/virtio_vdpa.c | 21 ++++++++++++++++++++-
> include/linux/remoteproc.h | 3 +++
> include/linux/virtio_config.h | 6 +++---
> 12 files changed, 86 insertions(+), 19 deletions(-)
>
> base-commit: a500db7819c50db59e55f1b4fa1c3baa5a2616f3
> --
> 2.39.5 (Apple Git-154)
