Re: [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Sep 22, 2021 at 09:05:06AM -0400, Tony Krowiak wrote:
> 
> 
> On 9/21/21 8:11 AM, Jason Gunthorpe wrote:
> > Without this call an xarray entry is leaked when the vfio_ap device is
> > unprobed. It was missed when the below patch was rebased across the
> > dev_set patch. Keep the remove function in the same order as the error
> > unwind in probe.
> > 
> > Fixes: eb0feefd4c02 ("vfio/ap_ops: Convert to use vfio_register_group_dev()")
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Tested-by: Tony Krowiak <akrowiak@linux.ibm.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> >   drivers/s390/crypto/vfio_ap_ops.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > v3:
> >   - Keep the remove sequence the same as remove to avoid a lockdep splat
> > v2: https://lore.kernel.org/r/0-v2-25656bbbb814+41-ap_uninit_jgg@nvidia.com/
> >   - Fix corrupted diff
> > v1: https://lore.kernel.org/r/0-v1-3a05c6000668+2ce62-ap_uninit_jgg@nvidia.com/
> > 
> > diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> > index 118939a7729a1e..623d5269a52ce5 100644
> > +++ b/drivers/s390/crypto/vfio_ap_ops.c
> > @@ -361,6 +361,7 @@ static int vfio_ap_mdev_probe(struct mdev_device *mdev)
> >   	mutex_lock(&matrix_dev->lock);
> >   	list_del(&matrix_mdev->node);
> >   	mutex_unlock(&matrix_dev->lock);
> > +	vfio_uninit_group_dev(&matrix_mdev->vdev);
> >   	kfree(matrix_mdev);
> >   err_dec_available:
> >   	atomic_inc(&matrix_dev->available_instances);
> > @@ -376,9 +377,10 @@ static void vfio_ap_mdev_remove(struct mdev_device *mdev)
> >   	mutex_lock(&matrix_dev->lock);
> >   	vfio_ap_mdev_reset_queues(matrix_mdev);
> >   	list_del(&matrix_mdev->node);
> > +	mutex_unlock(&matrix_dev->lock);
> > +	vfio_uninit_group_dev(&matrix_mdev->vdev);
> >   	kfree(matrix_mdev);
> >   	atomic_inc(&matrix_dev->available_instances);
> 
> I think the above line of code should be done under the
> matrix_dev->lock after removing the matrix_mdev from
> the list since it is changing a value in matrix_dev.

No, the read-side doesn't hold the lock

	if ((atomic_dec_if_positive(&matrix_dev->available_instances) < 0))
		return -EPERM;

I think it is just a leftover from the atomic conversion that Alex
did to keep it under the matrix_dev struct.

If we were going to hold the lock then it wouldn't need to be an
atomic.

Jason