Skip to contentSkip to conversation

vdpa/vp_vdpa: Wait for device reset to complete

PATCH New Yuho Choi 2 participants 2 messages Sep 26

Subsystems (2)
lore
Share & tools
lore

Yuho Choi

author
#0 lore raw

PATCH 1/1 vdpa/vp_vdpa: Wait for device reset to complete

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")

---
Compile-tested only (x86_64 defconfig + VP_VDPA, W=1).

 drivers/vdpa/virtio_pci/vp_vdpa.c | 4 ++++
 1 file changed, 4 insertions(+)
drivers/vdpa/virtio_pci/vp_vdpa.c +4 -0
index f2eb654b1665..4285cb968479 100644
@@ -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

Signature · 1 line
2.43.0
#1 lore raw
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 --

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 <[email protected]>

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.

Quoted 4 lines
drivers/vdpa/virtio_pci/vp_vdpa.c +0 -0
index f2eb654b1665a..4285cb968479a 100644

[ ... ]

drivers/vdpa/virtio_pci/vp_vdpa.c static int vp_vdpa_reset(struct vdpa_device *vdpa) · line 242

Quoted 7 lines
drivers/vdpa/virtio_pci/vp_vdpa.c +3 -0
@@ -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?

Quoted 3 lines
drivers/vdpa/virtio_pci/vp_vdpa.c +0 -0
 	if (s & VIRTIO_CONFIG_S_DRIVER_OK)
 		vp_vdpa_free_irq(vp_vdpa);
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1