Re: [PATCH v3 03/15] s390/vfio-ap: Initialize/release vfio device migration data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Self-deadlock in the error path of vfio_ap_mdev_probe() when vfio_register_emulated_iommu_dev() fails.
--

commit 5aa03de641783e67e8d873c30619dc8b515b536e
Author: Anthony Krowiak <akrowiak@linux.ibm.com>

s390/vfio-ap: Initialize/release vfio device migration data

This commit provides functions to initialize and release data structures
used during live guest migration. It also adds a release callback for the
vfio device to clean up the migration data when the mdev is released.

> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
[ ... ]
> +static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
> +{
> +	struct ap_matrix_mdev *matrix_mdev;
> +
> +	mutex_lock(&matrix_dev->mdevs_lock);
> +	matrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev);
> +	vfio_ap_release_migration_data(matrix_mdev);
> +	mutex_unlock(&matrix_dev->mdevs_lock);
> +}
> +
>  static int vfio_ap_mdev_probe(struct mdev_device *mdev)
[ ... ]
> @@ -797,19 +809,30 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
>  	if (IS_ERR(matrix_mdev))
>  		return PTR_ERR(matrix_mdev);
>  
> +	mutex_lock(&matrix_dev->mdevs_lock);
> +
[ ... ]
>  	ret = vfio_register_emulated_iommu_dev(&matrix_mdev->vdev);
>  	if (ret)
>  		goto err_put_vdev;
[ ... ]
>  err_put_vdev:
>  	vfio_put_device(&matrix_mdev->vdev);
> +	mutex_unlock(&matrix_dev->mdevs_lock);

[Severity: High]
Does this create a self-deadlock when vfio_register_emulated_iommu_dev()
fails?

In this error path, matrix_dev->mdevs_lock is held when calling
vfio_put_device(). If this drops the last reference, it will synchronously
invoke the device's release callback, vfio_ap_mdev_release_dev().

Looking at the newly added vfio_ap_mdev_release_dev() above, it
unconditionally attempts to acquire the exact same matrix_dev->mdevs_lock.
Could this cause the thread to hang indefinitely since the non-recursive
lock is already held by vfio_ap_mdev_probe()?

>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630104132.1598851-1-akrowiak@linux.ibm.com?part=3