[PATCH v1] vdpa/vp_vdpa: Wait for device reset to complete

[PATCH v1] vdpa/vp_vdpa: Wait for device reset to complete

[Yuho Choi]

vp_vdpa_reset() writes 0 to device_status and returns success right
away. The virtio specification requires the driver to wait until a read
of device_status returns 0 before reinitializing the device, and
virtio_pci_modern's vp_reset() does exactly that: the read-back flushes
the posted status write and any in-flight device writes, including
MSI-X messages.

Without it, vhost-vdpa (or virtio-vdpa) can go on to tear down the
IOTLB/IOMMU mappings or reprogram the queues while the device has not
yet finished its reset, and may still be DMAing to the old virtqueue
addresses. The MSI-X vectors are also freed while an interrupt from
the old configuration may still be in flight.

Poll device_status after writing 0, in the same way as vp_reset(),
before freeing the IRQs and returning.

Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver")
Cc: stable@vger.kernel.org
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
Compile-tested only (x86_64 defconfig + VP_VDPA, W=1).

 drivers/vdpa/virtio_pci/vp_vdpa.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c b/drivers/vdpa/virtio_pci/vp_vdpa.c
index f2eb654b1665..4285cb968479 100644
--- a/drivers/vdpa/virtio_pci/vp_vdpa.c
+++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
@@ -8,6 +8,7 @@
  * Based on virtio_pci_modern.c.
  */
 
+#include <linux/delay.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
 #include <linux/pci.h>
@@ -236,6 +237,9 @@ static int vp_vdpa_reset(struct vdpa_device *vdpa)
 	u8 s = vp_vdpa_get_status(vdpa);
 
 	vp_modern_set_status(mdev, 0);
+	/* Wait for the reset to complete */
+	while (vp_modern_get_status(mdev))
+		fsleep(1000);
 
 	if (s & VIRTIO_CONFIG_S_DRIVER_OK)
 		vp_vdpa_free_irq(vp_vdpa);

base-commit: aa98230e410f0ed212b6788c46b1e4d49e0ff7ca
-- 
2.43.0

Re: [PATCH v1] vdpa/vp_vdpa: Wait for device reset to complete

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] vdpa: infinite wait in vp_vdpa_reset() on surprise removal
--

commit ae50410e662342786548e32b0e3164421c8c5862
Author: Yuho Choi <oss.patchbox@gmail.com>

vdpa/vp_vdpa: Wait for device reset to complete

This commit modifies vp_vdpa_reset() to poll the device status after writing
0, waiting for it to become 0. This ensures the device reset completes before
tearing down IOTLB/IOMMU mappings or freeing IRQs.

> diff --git a/drivers/vdpa/virtio_pci/vp_vdpa.c b/drivers/vdpa/virtio_pci/vp_vdpa.c
> index f2eb654b1665a..4285cb968479a 100644
> --- a/drivers/vdpa/virtio_pci/vp_vdpa.c
> +++ b/drivers/vdpa/virtio_pci/vp_vdpa.c
[ ... ]
> @@ -236,6 +237,9 @@ static int vp_vdpa_reset(struct vdpa_device *vdpa)
>  	u8 s = vp_vdpa_get_status(vdpa);
>  
>  	vp_modern_set_status(mdev, 0);
> +	/* Wait for the reset to complete */
> +	while (vp_modern_get_status(mdev))
> +		fsleep(1000);

[Severity: High]
Could this unbounded wait cause an infinite loop during a surprise removal?

If the underlying PCI device undergoes a surprise removal (hot-unplug) or a
fatal bus error, memory-mapped I/O reads via vp_modern_get_status() will
persistently return all-ones (0xFF).

Since there is no timeout or explicit check for the 0xFF PCIe disconnect
state, could this lead to a permanent kernel thread hang in uninterruptible
sleep?

>  
>  	if (s & VIRTIO_CONFIG_S_DRIVER_OK)
>  		vp_vdpa_free_irq(vp_vdpa);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926211507.1330179-1-oss.patchbox@gmail.com?part=1