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. > 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/[email protected]?part=1
