On Wed, 22 Sep 2021 10:11:50 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
> 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@xxxxxx>
> > > Tested-by: Tony Krowiak <akrowiak@xxxxxxxxxxxxx>
> > > Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > > 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@xxxxxxxxxx/
> > > - Fix corrupted diff
> > > v1: https://lore.kernel.org/r/0-v1-3a05c6000668+2ce62-ap_uninit_jgg@xxxxxxxxxx/
> > >
> > > 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.
Tony, I'd love to get an ack if you're satisfied with this so we can
close up fixes for v5.15. Thanks,
Alex
