All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.ibm.com>
To: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Cc: jjherne@linux.ibm.com, freude@linux.ibm.com,
	borntraeger@de.ibm.com, cohuck@redhat.com,
	mjrosato@linux.ibm.com, pasic@linux.ibm.com,
	alex.williamson@redhat.com, kwankhede@nvidia.com,
	fiuczy@linux.ibm.com, Tony Krowiak <akrowiak@linux.ibm.com>
Subject: [PATCH v17 12/15] s390/vfio-ap: implement in-use callback for vfio_ap driver
Date: Thu, 21 Oct 2021 11:23:29 -0400	[thread overview]
Message-ID: <20211021152332.70455-13-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20211021152332.70455-1-akrowiak@linux.ibm.com>

Let's implement the callback to indicate when an APQN
is in use by the vfio_ap device driver. The callback is
invoked whenever a change to the apmask or aqmask would
result in one or more queue devices being removed from the driver. The
vfio_ap device driver will indicate a resource is in use
if the APQN of any of the queue devices to be removed are assigned to
any of the matrix mdevs under the driver's control.

There is potential for a deadlock condition between the matrix_dev->lock
used to lock the matrix device during assignment of adapters and domains
and the ap_perms_mutex locked by the AP bus when changes are made to the
sysfs apmask/aqmask attributes.

Consider following scenario (courtesy of Halil Pasic):
1) apmask_store() takes ap_perms_mutex
2) assign_adapter_store() takes matrix_dev->lock
3) apmask_store() calls vfio_ap_mdev_resource_in_use() which tries
to take matrix_dev->lock
4) assign_adapter_store() calls ap_apqn_in_matrix_owned_by_def_drv
which tries to take ap_perms_mutex
BANG!

To resolve this issue, instead of using the mutex_lock(&matrix_dev->lock)
function to lock the matrix device during assignment of an adapter or
domain to a matrix_mdev as well as during the in_use callback, the
mutex_trylock(&matrix_dev->lock) function will be used. If the lock is not
obtained, then the assignment and in_use functions will terminate with
-EAGAIN.

Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_drv.c     |  1 +
 drivers/s390/crypto/vfio_ap_ops.c     | 80 ++++++++++++++++++++++++---
 drivers/s390/crypto/vfio_ap_private.h |  2 +
 3 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
index 1d1746fe50ea..df7528dcf6ed 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -44,6 +44,7 @@ MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
 static struct ap_driver vfio_ap_drv = {
 	.probe = vfio_ap_mdev_probe_queue,
 	.remove = vfio_ap_mdev_remove_queue,
+	.in_use = vfio_ap_mdev_resource_in_use,
 	.ids = ap_queue_ids,
 };
 
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 6b292ed30ada..5386b8635bec 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -635,16 +635,45 @@ static void vfio_ap_mdev_link_adapter(struct ap_matrix_mdev *matrix_mdev,
  * vfio_ap_mdev_get_locks - lock the kvm->lock and matrix_dev->lock mutexes
  *
  * @matrix_mdev: the matrix mediated device object
+ * @check_mdev_lock: indicates whether to check that the matrix_dev->lock mutex
+ *		     is already locked (true = check, false = do not check).
+ *
+ * Return:
+ *	-EAGAIN if the matrix_dev->lock mutex is already locked.
+ *	0 if both locks were acquired.
  */
-static void vfio_ap_mdev_get_locks(struct ap_matrix_mdev *matrix_mdev)
+static int vfio_ap_mdev_get_locks(struct ap_matrix_mdev *matrix_mdev,
+				  bool check_mdev_lock)
 {
+	/*
+	 * If the matrix_dev->lock mutex is to be checked, then there's no
+	 * sense in proceding if it is already locked.
+	 */
+	if (check_mdev_lock && mutex_is_locked(&matrix_dev->lock))
+		return -EAGAIN;
+
 	down_read(&matrix_dev->guests_lock);
 
 	/* The kvm->lock must be must be taken before the matrix_dev->lock */
 	if (matrix_mdev->guest)
 		mutex_lock(&matrix_mdev->guest->kvm->lock);
 
-	mutex_lock(&matrix_dev->lock);
+	/*
+	 * If the matrix_dev-> lock is to be checked, then let's try to acquire
+	 * it. If it can't be acquired, then let's bail out and return
+	 * a value indicating locking should be tried again.
+	 */
+	if (check_mdev_lock) {
+		if (!mutex_trylock(&matrix_dev->lock)) {
+			mutex_unlock(&matrix_mdev->guest->kvm->lock);
+			up_read(&matrix_dev->guests_lock);
+			return -EAGAIN;
+		}
+	} else {
+		mutex_lock(&matrix_dev->lock);
+	}
+
+	return 0;
 }
 
 /**
@@ -654,7 +683,6 @@ static void vfio_ap_mdev_get_locks(struct ap_matrix_mdev *matrix_mdev)
  */
 static void vfio_ap_mdev_put_locks(struct ap_matrix_mdev *matrix_mdev)
 {
-	/* The kvm->lock must be must be taken before the matrix_dev->lock */
 	if (matrix_mdev->guest)
 		mutex_unlock(&matrix_mdev->guest->kvm->lock);
 
@@ -691,6 +719,10 @@ static void vfio_ap_mdev_put_locks(struct ap_matrix_mdev *matrix_mdev)
  *	   An APQN derived from the cross product of the APID being assigned
  *	   and the APQIs previously assigned is being used by another mediated
  *	   matrix device
+ *
+ *     5. -EAGAIN
+ *        The mdev lock could not be acquired which is required in order to
+ *        change the AP configuration for the mdev
  */
 static ssize_t assign_adapter_store(struct device *dev,
 				    struct device_attribute *attr,
@@ -707,7 +739,10 @@ static ssize_t assign_adapter_store(struct device *dev,
 	if (apid > matrix_mdev->matrix.apm_max)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, true);
+	if (ret)
+		return ret;
+
 	set_bit_inv(apid, matrix_mdev->matrix.apm);
 
 	ret = vfio_ap_mdev_validate_masks(matrix_mdev);
@@ -815,7 +850,10 @@ static ssize_t unassign_adapter_store(struct device *dev,
 	if (apid > matrix_mdev->matrix.apm_max)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, false);
+	if (ret)
+		return ret;
+
 	clear_bit_inv((unsigned long)apid, matrix_mdev->matrix.apm);
 	vfio_ap_mdev_hot_unplug_adapter(matrix_mdev, apid);
 	vfio_ap_mdev_put_locks(matrix_mdev);
@@ -879,7 +917,10 @@ static ssize_t assign_domain_store(struct device *dev,
 	if (apqi > max_apqi)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, true);
+	if (ret)
+		return ret;
+
 	set_bit_inv(apqi, matrix_mdev->matrix.aqm);
 
 	ret = vfio_ap_mdev_validate_masks(matrix_mdev);
@@ -962,7 +1003,10 @@ static ssize_t unassign_domain_store(struct device *dev,
 	if (apqi > matrix_mdev->matrix.aqm_max)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, false);
+	if (ret)
+		return ret;
+
 	clear_bit_inv((unsigned long)apqi, matrix_mdev->matrix.aqm);
 	vfio_ap_mdev_hot_unplug_domain(matrix_mdev, apqi);
 	vfio_ap_mdev_put_locks(matrix_mdev);
@@ -1000,7 +1044,9 @@ static ssize_t assign_control_domain_store(struct device *dev,
 	if (id > matrix_mdev->matrix.adm_max)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, false);
+	if (ret)
+		return ret;
 
 	/* Set the bit in the ADM (bitmask) corresponding to the AP control
 	 * domain number (id). The bits in the mask, from most significant to
@@ -1047,7 +1093,10 @@ static ssize_t unassign_control_domain_store(struct device *dev,
 	if (domid > max_domid)
 		return -ENODEV;
 
-	vfio_ap_mdev_get_locks(matrix_mdev);
+	ret = vfio_ap_mdev_get_locks(matrix_mdev, false);
+	if (ret)
+		return ret;
+
 	clear_bit_inv(domid, matrix_mdev->matrix.adm);
 
 	if (vfio_ap_mdev_filter_cdoms(matrix_mdev))
@@ -1681,3 +1730,16 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
 	vfio_ap_mdev_put_qlocks(guest);
 	kfree(q);
 }
+
+int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm)
+{
+	int ret;
+
+	if (!mutex_trylock(&matrix_dev->lock))
+		return -EBUSY;
+
+	ret = vfio_ap_mdev_verify_no_sharing(apm, aqm);
+	mutex_unlock(&matrix_dev->lock);
+
+	return ret;
+}
diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
index 5d59bba8b153..97da41f87c65 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -149,4 +149,6 @@ void vfio_ap_mdev_unregister(void);
 int vfio_ap_mdev_probe_queue(struct ap_device *queue);
 void vfio_ap_mdev_remove_queue(struct ap_device *queue);
 
+int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm);
+
 #endif /* _VFIO_AP_PRIVATE_H_ */
-- 
2.31.1


  parent reply	other threads:[~2021-10-21 15:24 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 15:23 [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 01/15] s390/vfio-ap: Set pqap hook when vfio_ap module is loaded Tony Krowiak
2021-12-27  8:21   ` Halil Pasic
2022-01-11 21:13     ` Tony Krowiak
2022-01-04 16:22   ` Jason J. Herne
2022-01-11 17:29     ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 02/15] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2021-12-27  8:25   ` Halil Pasic
2022-01-11 17:32     ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 03/15] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 04/15] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 05/15] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 06/15] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2021-12-27  8:53   ` Halil Pasic
2022-01-11 21:19     ` Tony Krowiak
2022-01-12 11:52       ` Halil Pasic
2022-01-15  0:31         ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 07/15] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2021-12-27  9:06   ` Halil Pasic
2021-10-21 15:23 ` [PATCH v17 08/15] s390/vfio-ap: keep track of active guests Tony Krowiak
2021-12-30  2:04   ` Halil Pasic
2022-01-11 21:27     ` Tony Krowiak
2021-12-30  3:33   ` Halil Pasic
2022-01-11 21:58     ` Tony Krowiak
2022-01-11 22:19       ` Tony Krowiak
2022-01-12 14:25       ` Halil Pasic
2022-01-15  0:29         ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 09/15] s390/vfio-ap: allow hot plug/unplug of AP resources using mdev device Tony Krowiak
2022-01-09 21:36   ` Halil Pasic
2022-01-11 22:42     ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 10/15] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 11/15] s390/ap: driver callback to indicate resource in use Tony Krowiak
2021-11-04 11:27   ` Harald Freudenberger
2021-11-04 15:48     ` Tony Krowiak
2021-10-21 15:23 ` Tony Krowiak [this message]
2021-10-21 15:23 ` [PATCH v17 13/15] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 14/15] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2021-11-04 12:06   ` Harald Freudenberger
2021-11-04 15:50     ` Tony Krowiak
2021-11-05  8:23       ` Harald Freudenberger
2021-11-05 13:15         ` Harald Freudenberger
2021-11-08 14:27           ` Tony Krowiak
2021-11-08 14:26         ` Tony Krowiak
2022-02-04 10:43   ` Halil Pasic
2022-02-07 19:39     ` Tony Krowiak
2022-02-08  1:38       ` Halil Pasic
2022-02-08  3:27         ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 15/15] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2021-10-27 14:24 ` [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-11-02 19:23   ` Tony Krowiak
2021-11-15 15:45 ` Tony Krowiak
2021-11-22 16:12 ` 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=20211021152332.70455-13-akrowiak@linux.ibm.com \
    --to=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.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 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.