All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()
@ 2021-09-21 12:11 Jason Gunthorpe
  2021-09-22 13:05 ` Tony Krowiak
  0 siblings, 1 reply; 5+ messages in thread
From: Jason Gunthorpe @ 2021-09-21 12:11 UTC (permalink / raw)
  To: Christian Borntraeger, Harald Freudenberger, Vasily Gorbik,
	Heiko Carstens, Jason Herne, linux-s390, Halil Pasic
  Cc: Tony Krowiak, Alex Williamson, Cornelia Huck, Christoph Hellwig, kvm

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
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ 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);
-	mutex_unlock(&matrix_dev->lock);
 }
 
 static ssize_t name_show(struct mdev_type *mtype,

base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f
-- 
2.33.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread
* Re: [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()
  2021-09-21 12:11 [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev() Jason Gunthorpe
@ 2021-09-22 13:05 ` Tony Krowiak
  2021-09-22 13:11   ` Jason Gunthorpe
  0 siblings, 1 reply; 5+ messages in thread
From: Tony Krowiak @ 2021-09-22 13:05 UTC (permalink / raw)
  To: Jason Gunthorpe, Christian Borntraeger, Harald Freudenberger,
	Vasily Gorbik, Heiko Carstens, Jason Herne, linux-s390,
	Halil Pasic
  Cc: Alex Williamson, Cornelia Huck, Christoph Hellwig, kvm



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
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ 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.


> -	mutex_unlock(&matrix_dev->lock);
>   }
>   
>   static ssize_t name_show(struct mdev_type *mtype,
>
> base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()
  2021-09-22 13:05 ` Tony Krowiak
@ 2021-09-22 13:11   ` Jason Gunthorpe
  2021-09-23 20:10     ` Alex Williamson
  0 siblings, 1 reply; 5+ messages in thread
From: Jason Gunthorpe @ 2021-09-22 13:11 UTC (permalink / raw)
  To: Tony Krowiak
  Cc: Christian Borntraeger, Harald Freudenberger, Vasily Gorbik,
	Heiko Carstens, Jason Herne, linux-s390, Halil Pasic,
	Alex Williamson, Cornelia Huck, Christoph Hellwig, kvm

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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()
  2021-09-22 13:11   ` Jason Gunthorpe
@ 2021-09-23 20:10     ` Alex Williamson
  2021-09-24  2:24       ` Tony Krowiak
  0 siblings, 1 reply; 5+ messages in thread
From: Alex Williamson @ 2021-09-23 20:10 UTC (permalink / raw)
  To: Tony Krowiak
  Cc: Jason Gunthorpe, Christian Borntraeger, Harald Freudenberger,
	Vasily Gorbik, Heiko Carstens, Jason Herne, linux-s390,
	Halil Pasic, Cornelia Huck, Christoph Hellwig, kvm

On Wed, 22 Sep 2021 10:11:50 -0300
Jason Gunthorpe <jgg@nvidia.com> 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@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.

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


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev()
  2021-09-23 20:10     ` Alex Williamson
@ 2021-09-24  2:24       ` Tony Krowiak
  0 siblings, 0 replies; 5+ messages in thread
From: Tony Krowiak @ 2021-09-24  2:24 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Jason Gunthorpe, Christian Borntraeger, Harald Freudenberger,
	Vasily Gorbik, Heiko Carstens, Jason Herne, linux-s390,
	Halil Pasic, Cornelia Huck, Christoph Hellwig, kvm



On 9/23/21 4:10 PM, Alex Williamson wrote:

> 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

Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>

>


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-24  2:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-21 12:11 [PATCH v3] vfio/ap_ops: Add missed vfio_uninit_group_dev() Jason Gunthorpe
2021-09-22 13:05 ` Tony Krowiak
2021-09-22 13:11   ` Jason Gunthorpe
2021-09-23 20:10     ` Alex Williamson
2021-09-24  2:24       ` Tony Krowiak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.