public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Tony Krowiak <akrowiak@linux.ibm.com>
Cc: jjherne@linux.ibm.com, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, borntraeger@de.ibm.com,
	cohuck@redhat.com, pasic@linux.vnet.ibm.com,
	alex.williamson@redhat.com, kwankhede@nvidia.com,
	frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
	hca@linux.ibm.com
Subject: Re: [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler
Date: Tue, 25 May 2021 13:29:27 -0300	[thread overview]
Message-ID: <20210525162927.GC1002214@nvidia.com> (raw)
In-Reply-To: <c54ef522-f348-df16-a99f-1e31feb1b0bd@linux.ibm.com>

On Tue, May 25, 2021 at 11:56:50AM -0400, Tony Krowiak wrote:

> The vfio_ap_mdev_unset_kvm() function, however, is called both by
> the group notifier when the KVM pointer has been cleared or when the
> mdev is being removed. In both cases, the only way to get the KVM
> pointer - which is needed to unplug the AP resources from the guest
> - is from the matrix_mdev which contains it.

Okay, but that isn't a problem, the matrix dev holds a ref on the kvm
pointer so we can just copy it outside the lock after we prevent it
from changing by unregistering the notifier:

@@ -1362,14 +1365,19 @@ static void vfio_ap_mdev_release(struct mdev_device *mdev)
 {
        struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
 
-       mutex_lock(&matrix_dev->lock);
-       vfio_ap_mdev_unset_kvm(matrix_mdev);
-       mutex_unlock(&matrix_dev->lock);
-
        vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
                                 &matrix_mdev->iommu_notifier);
        vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
                                 &matrix_mdev->group_notifier);
+
+       mutex_lock(&matrix_dev->lock);
+       /* matrix_dev->kvm cannot be changed now since we removed the notifiers */
+       kvm = matrix_mdev->kvm;
+       matrix_mdev->kvm = NULL;
+       mutex_unlock(&matrix_dev->lock);
+
+       vfio_ap_mdev_unset_kvm(matrix_mdev, kvm);
+
        module_put(THIS_MODULE);

Note the above misordering is an existing bug too

And reoganize unset_kvm so it uses internal locking and gets the kvm
from the argument.

Also the kvm_busy should be replaced by a proper rwsem, don't try to
open code locks like that - it just defeats lockdep analysis.

Finally, since the only way the ->kvm can be become non-NULL is if the
notifier is registered, release above removes the notifier, and remove
can't be called unless release has been completed, it looks to me like
this the remove check is just dead code, delete it, or leave it as a
WARN_ON:

@@ -366,16 +366,6 @@ static int vfio_ap_mdev_remove(struct mdev_device *mdev)
        struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);

        mutex_lock(&matrix_dev->lock);
-
-       /*
-        * If the KVM pointer is in flux or the guest is running, disallow
-        * un-assignment of control domain.
-        */
-       if (matrix_mdev->kvm_busy || matrix_mdev->kvm) {
-               mutex_unlock(&matrix_dev->lock);
-               return -EBUSY;
-       }

Jason

  reply	other threads:[~2021-05-25 16:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 19:36 [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Tony Krowiak
2021-05-21 19:36 ` [PATCH v4 1/2] " Tony Krowiak
2021-05-25 13:03   ` Halil Pasic
2021-05-25 13:22     ` Tony Krowiak
2021-05-26 12:37     ` Tony Krowiak
2021-05-21 19:36 ` [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler Tony Krowiak
2021-05-23 22:57   ` Jason Gunthorpe
2021-05-25 14:59     ` Tony Krowiak
2021-05-25 15:00       ` Jason Gunthorpe
2021-05-24 14:37   ` Jason J. Herne
2021-05-25 13:16     ` Tony Krowiak
2021-05-25 13:19       ` Jason Gunthorpe
2021-05-25 15:08         ` Tony Krowiak
2021-05-25 15:11           ` Jason Gunthorpe
2021-05-25 15:56         ` Tony Krowiak
2021-05-25 16:29           ` Jason Gunthorpe [this message]
2021-05-27  2:28             ` Tony Krowiak
2021-05-27 11:24               ` Jason Gunthorpe
2021-05-25 13:24     ` Jason J. Herne
2021-05-25 13:26       ` Jason Gunthorpe
2021-05-25 14:07         ` Jason J. Herne
2021-05-25 14:16           ` Jason Gunthorpe
2021-06-14  7:51 ` [PATCH v4 0/2] s390/vfio-ap: fix memory leak in mdev remove callback Christian Borntraeger
2021-06-16 14:24   ` Tony Krowiak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210525162927.GC1002214@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox