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

[sashiko-bot@kernel.org]

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