intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
@ 2023-01-31 20:06 Matthew Rosato
  2023-01-31 20:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
                   ` (4 more replies)
  0 siblings, 5 replies; 11+ messages in thread
From: Matthew Rosato @ 2023-01-31 20:06 UTC (permalink / raw)
  To: alex.williamson, pbonzini, yi.l.liu, jgg
  Cc: akrowiak, jjherne, farman, borntraeger, frankja, pmorel, david,
	seanjc, intel-gfx, cohuck, linux-kernel, pasic, kvm, linux-s390,
	imbrenda, intel-gvt-dev

After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order.  Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like vfio-ap) need to acquire kvm->lock during their open_device
routine;  Meanwhile, kvm_vfio_release will acquire the kvm->lock first
before calling vfio_file_set_kvm which will acquire the vfio group_lock.

To resolve this, let's remove the need for the vfio group_lock from the
kvm_vfio_release codepath.  This is done by introducing a new spinlock to
protect modifications to the vfio group kvm pointer, and acquiring a kvm
ref from within vfio while holding this spinlock, with the reference held
until the last close for the device in question.

Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
Reported-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
---
 drivers/vfio/group.c     | 14 +++----
 drivers/vfio/vfio.h      |  5 ++-
 drivers/vfio/vfio_main.c | 88 ++++++++++++++++++++++++++++++++++++----
 include/linux/vfio.h     |  2 +-
 4 files changed, 88 insertions(+), 21 deletions(-)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index bb24b2f0271e..8f67d33e0e8d 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -164,13 +164,7 @@ static int vfio_device_group_open(struct vfio_device *device)
 		goto out_unlock;
 	}
 
-	/*
-	 * Here we pass the KVM pointer with the group under the lock.  If the
-	 * device driver will use it, it must obtain a reference and release it
-	 * during close_device.
-	 */
-	ret = vfio_device_open(device, device->group->iommufd,
-			       device->group->kvm);
+	ret = vfio_device_open(device, device->group);
 
 out_unlock:
 	mutex_unlock(&device->group->group_lock);
@@ -450,6 +444,7 @@ static struct vfio_group *vfio_group_alloc(struct iommu_group *iommu_group,
 
 	refcount_set(&group->drivers, 1);
 	mutex_init(&group->group_lock);
+	spin_lock_init(&group->kvm_ref_lock);
 	INIT_LIST_HEAD(&group->device_list);
 	mutex_init(&group->device_lock);
 	group->iommu_group = iommu_group;
@@ -799,13 +794,14 @@ EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
 void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
 {
 	struct vfio_group *group = file->private_data;
+	unsigned long flags;
 
 	if (!vfio_file_is_group(file))
 		return;
 
-	mutex_lock(&group->group_lock);
+	spin_lock_irqsave(&group->kvm_ref_lock, flags);
 	group->kvm = kvm;
-	mutex_unlock(&group->group_lock);
+	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
 }
 EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
 
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index f8219a438bfb..d153ad35de24 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -15,11 +15,11 @@ struct iommufd_ctx;
 struct iommu_group;
 struct vfio_device;
 struct vfio_container;
+struct vfio_group;
 
 void vfio_device_put_registration(struct vfio_device *device);
 bool vfio_device_try_get_registration(struct vfio_device *device);
-int vfio_device_open(struct vfio_device *device,
-		     struct iommufd_ctx *iommufd, struct kvm *kvm);
+int vfio_device_open(struct vfio_device *device, struct vfio_group *group);
 void vfio_device_close(struct vfio_device *device,
 		       struct iommufd_ctx *iommufd);
 
@@ -74,6 +74,7 @@ struct vfio_group {
 	struct file			*opened_file;
 	struct blocking_notifier_head	notifier;
 	struct iommufd_ctx		*iommufd;
+	spinlock_t			kvm_ref_lock;
 };
 
 int vfio_device_set_group(struct vfio_device *device,
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 5177bb061b17..b0defb0d0d87 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -16,6 +16,9 @@
 #include <linux/fs.h>
 #include <linux/idr.h>
 #include <linux/iommu.h>
+#ifdef CONFIG_HAVE_KVM
+#include <linux/kvm_host.h>
+#endif
 #include <linux/list.h>
 #include <linux/miscdevice.h>
 #include <linux/module.h>
@@ -344,9 +347,59 @@ static bool vfio_assert_device_open(struct vfio_device *device)
 	return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
 }
 
+#ifdef CONFIG_HAVE_KVM
+static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
+{
+	void (*pfn)(struct kvm *kvm);
+	bool (*fn)(struct kvm *kvm);
+	bool ret;
+
+	pfn = symbol_get(kvm_put_kvm);
+	if (WARN_ON(!pfn))
+		return false;
+
+	fn = symbol_get(kvm_get_kvm_safe);
+	if (WARN_ON(!fn)) {
+		symbol_put(kvm_put_kvm);
+		return false;
+	}
+
+	ret = fn(kvm);
+	if (ret)
+		device->put_kvm = pfn;
+	else
+		symbol_put(kvm_put_kvm);
+
+	symbol_put(kvm_get_kvm_safe);
+
+	return ret;
+}
+
+static void vfio_kvm_put_kvm(struct vfio_device *device)
+{
+	if (WARN_ON(!device->kvm || !device->put_kvm))
+		return;
+
+	device->put_kvm(device->kvm);
+	symbol_put(kvm_put_kvm);
+}
+
+#else
+static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
+{
+	return false;
+}
+
+static void vfio_kvm_put_kvm(struct vfio_device *device)
+{
+}
+#endif
+
 static int vfio_device_first_open(struct vfio_device *device,
-				  struct iommufd_ctx *iommufd, struct kvm *kvm)
+				  struct vfio_group *group)
 {
+	struct iommufd_ctx *iommufd = group->iommufd;
+	unsigned long flags;
 	int ret;
 
 	lockdep_assert_held(&device->dev_set->lock);
@@ -361,16 +414,30 @@ static int vfio_device_first_open(struct vfio_device *device,
 	if (ret)
 		goto err_module_put;
 
-	device->kvm = kvm;
+	/*
+	 * Get the KVM pointer currently associated with the group, if there
+	 * is one, and obtain a reference now that will be held until the
+	 * open_count reaches 0.  Save the pointer in the device for use by
+	 * drivers.
+	 */
+	spin_lock_irqsave(&group->kvm_ref_lock, flags);
+	if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
+		device->kvm = group->kvm;
+	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
+
 	if (device->ops->open_device) {
 		ret = device->ops->open_device(device);
 		if (ret)
-			goto err_unuse_iommu;
+			goto err_put_kvm;
 	}
 	return 0;
 
-err_unuse_iommu:
-	device->kvm = NULL;
+err_put_kvm:
+	if (device->kvm) {
+		vfio_kvm_put_kvm(device);
+		device->put_kvm = NULL;
+		device->kvm = NULL;
+	}
 	if (iommufd)
 		vfio_iommufd_unbind(device);
 	else
@@ -387,7 +454,11 @@ static void vfio_device_last_close(struct vfio_device *device,
 
 	if (device->ops->close_device)
 		device->ops->close_device(device);
-	device->kvm = NULL;
+	if (device->kvm) {
+		vfio_kvm_put_kvm(device);
+		device->kvm = NULL;
+		device->put_kvm = NULL;
+	}
 	if (iommufd)
 		vfio_iommufd_unbind(device);
 	else
@@ -395,15 +466,14 @@ static void vfio_device_last_close(struct vfio_device *device,
 	module_put(device->dev->driver->owner);
 }
 
-int vfio_device_open(struct vfio_device *device,
-		     struct iommufd_ctx *iommufd, struct kvm *kvm)
+int vfio_device_open(struct vfio_device *device, struct vfio_group *group)
 {
 	int ret = 0;
 
 	mutex_lock(&device->dev_set->lock);
 	device->open_count++;
 	if (device->open_count == 1) {
-		ret = vfio_device_first_open(device, iommufd, kvm);
+		ret = vfio_device_first_open(device, group);
 		if (ret)
 			device->open_count--;
 	}
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 35be78e9ae57..87ff862ff555 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -46,7 +46,6 @@ struct vfio_device {
 	struct vfio_device_set *dev_set;
 	struct list_head dev_set_list;
 	unsigned int migration_flags;
-	/* Driver must reference the kvm during open_device or never touch it */
 	struct kvm *kvm;
 
 	/* Members below here are private, not for driver use */
@@ -58,6 +57,7 @@ struct vfio_device {
 	struct list_head group_next;
 	struct list_head iommu_entry;
 	struct iommufd_access *iommufd_access;
+	void (*put_kvm)(struct kvm *kvm);
 #if IS_ENABLED(CONFIG_IOMMUFD)
 	struct iommufd_device *iommufd_device;
 	struct iommufd_ctx *iommufd_ictx;
-- 
2.39.1


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
@ 2023-01-31 20:20 ` Patchwork
  2023-01-31 20:25 ` [Intel-gfx] [PATCH] " Jason Gunthorpe
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2023-01-31 20:20 UTC (permalink / raw)
  To: Matthew Rosato; +Cc: intel-gfx

== Series Details ==

Series: vfio: fix deadlock between group lock and kvm lock
URL   : https://patchwork.freedesktop.org/series/113535/
State : warning

== Summary ==

Error: dim checkpatch failed
22a38a2690cd vfio: fix deadlock between group lock and kvm lock
-:91: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#91: FILE: drivers/vfio/vfio.h:77:
+	spinlock_t			kvm_ref_lock;

total: 0 errors, 0 warnings, 1 checks, 203 lines checked



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
  2023-01-31 20:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2023-01-31 20:25 ` Jason Gunthorpe
  2023-02-01 12:43   ` Liu, Yi L
  2023-01-31 20:47 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2023-01-31 20:25 UTC (permalink / raw)
  To: Matthew Rosato
  Cc: kvm, david, imbrenda, linux-s390, yi.l.liu, frankja, pasic,
	borntraeger, jjherne, farman, intel-gfx, intel-gvt-dev, akrowiak,
	pmorel, seanjc, cohuck, linux-kernel, pbonzini

On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
> @@ -799,13 +794,14 @@ EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
>  void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
>  {
>  	struct vfio_group *group = file->private_data;
> +	unsigned long flags;
>  
>  	if (!vfio_file_is_group(file))
>  		return;
>  
> -	mutex_lock(&group->group_lock);
> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
>  	group->kvm = kvm;
> -	mutex_unlock(&group->group_lock);
> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);

We know we are in a sleeping context here so these are just
'spin_lock()', same with the other one

Otherwise it seems Ok to me

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BAT: failure for vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
  2023-01-31 20:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
  2023-01-31 20:25 ` [Intel-gfx] [PATCH] " Jason Gunthorpe
@ 2023-01-31 20:47 ` Patchwork
  2023-02-01  6:13 ` [Intel-gfx] [PATCH] " Tian, Kevin
  2023-02-01 12:42 ` Liu, Yi L
  4 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2023-01-31 20:47 UTC (permalink / raw)
  To: Matthew Rosato; +Cc: intel-gfx

[-- Attachment #1: Type: text/plain, Size: 7145 bytes --]

== Series Details ==

Series: vfio: fix deadlock between group lock and kvm lock
URL   : https://patchwork.freedesktop.org/series/113535/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12674 -> Patchwork_113535v1
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_113535v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_113535v1, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/index.html

Participating hosts (27 -> 26)
------------------------------

  Additional (1): fi-kbl-soraka 
  Missing    (2): bat-atsm-1 fi-snb-2520m 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_113535v1:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@execlists:
    - fi-bsw-n3050:       [PASS][1] -> [ABORT][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-bsw-n3050/igt@i915_selftest@live@execlists.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@slpc:
    - {bat-rpls-1}:       NOTRUN -> [DMESG-FAIL][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/bat-rpls-1/igt@i915_selftest@live@slpc.html

  
Known issues
------------

  Here are the changes found in Patchwork_113535v1 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@fbdev@write:
    - fi-blb-e6850:       [PASS][4] -> [SKIP][5] ([fdo#109271]) +4 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/fi-blb-e6850/igt@fbdev@write.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-blb-e6850/igt@fbdev@write.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html

  * igt@i915_selftest@live@execlists:
    - fi-kbl-soraka:      NOTRUN -> [INCOMPLETE][8] ([i915#7156])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@i915_selftest@live@execlists.html
    - fi-bsw-nick:        [PASS][9] -> [ABORT][10] ([i915#7911])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/fi-bsw-nick/igt@i915_selftest@live@execlists.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-bsw-nick/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][11] ([i915#5334] / [i915#7872])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
    - fi-kbl-7567u:       [PASS][12] -> [DMESG-FAIL][13] ([i915#5334] / [i915#7872])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][14] ([i915#1886])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][15] ([fdo#109271]) +15 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-kbl-soraka/igt@kms_chamelium_frames@hdmi-crc-fast.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@hangcheck:
    - {bat-dg2-11}:       [ABORT][16] ([i915#7913]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/bat-dg2-11/igt@i915_selftest@live@hangcheck.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/bat-dg2-11/igt@i915_selftest@live@hangcheck.html

  * igt@i915_selftest@live@requests:
    - {bat-rpls-1}:       [ABORT][18] ([i915#4983] / [i915#7981]) -> [PASS][19]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/bat-rpls-1/igt@i915_selftest@live@requests.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/bat-rpls-1/igt@i915_selftest@live@requests.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
    - fi-bsw-n3050:       [FAIL][20] ([i915#6298]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12674/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981


Build changes
-------------

  * Linux: CI_DRM_12674 -> Patchwork_113535v1

  CI-20190529: 20190529
  CI_DRM_12674: abcd161e6541aaf1e5c23e16019d02905c0e50fd @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7143: c7b12dcc460fc2348e1fa7f4dcb791bb82e29e44 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_113535v1: abcd161e6541aaf1e5c23e16019d02905c0e50fd @ git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

852ae00fca95 vfio: fix deadlock between group lock and kvm lock

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v1/index.html

[-- Attachment #2: Type: text/html, Size: 8244 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
                   ` (2 preceding siblings ...)
  2023-01-31 20:47 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
@ 2023-02-01  6:13 ` Tian, Kevin
  2023-02-01 14:27   ` Matthew Rosato
  2023-02-01 12:42 ` Liu, Yi L
  4 siblings, 1 reply; 11+ messages in thread
From: Tian, Kevin @ 2023-02-01  6:13 UTC (permalink / raw)
  To: Matthew Rosato, alex.williamson, pbonzini, Liu, Yi L, jgg
  Cc: akrowiak, jjherne, farman, borntraeger, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, linux-s390,
	imbrenda, intel-gvt-dev

> From: Matthew Rosato <mjrosato@linux.ibm.com>
> Sent: Wednesday, February 1, 2023 4:07 AM
> 
> -	device->kvm = kvm;
> +	/*
> +	 * Get the KVM pointer currently associated with the group, if there
> +	 * is one, and obtain a reference now that will be held until the
> +	 * open_count reaches 0.  Save the pointer in the device for use by
> +	 * drivers.
> +	 */
> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
> +	if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
> +		device->kvm = group->kvm;
> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
> +

No group reference in vfio_main.c. 

btw Yi, looks the deadlock issue also exists in your cdev work.

kvm_vfio_release() holds kvm lock and then try to acquire
device->device_set->lock in vfio_device_file_set_kvm().

vfio_device_ioctl_bind_iommufd() holds device->device_set->lock
and then call vfio_device_open() which finally hit kvm lock
acquisition in driver's open_device routine (e.g. vfio-ap).

A similar fix is required in your series.

Thanks
Kevin

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
                   ` (3 preceding siblings ...)
  2023-02-01  6:13 ` [Intel-gfx] [PATCH] " Tian, Kevin
@ 2023-02-01 12:42 ` Liu, Yi L
  2023-02-01 14:41   ` Matthew Rosato
  4 siblings, 1 reply; 11+ messages in thread
From: Liu, Yi L @ 2023-02-01 12:42 UTC (permalink / raw)
  To: Matthew Rosato, alex.williamson, pbonzini, jgg
  Cc: akrowiak, jjherne, farman, borntraeger, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, linux-s390,
	imbrenda, intel-gvt-dev

> From: Matthew Rosato <mjrosato@linux.ibm.com>
> Sent: Wednesday, February 1, 2023 4:07 AM
> 
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order.  Specifically in vfio_open_device, vfio
> holds the vfio group_lock when issuing device->ops->open_device but
> some
> drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> routine;  Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> 
> To resolve this, let's remove the need for the vfio group_lock from the
> kvm_vfio_release codepath.  This is done by introducing a new spinlock to
> protect modifications to the vfio group kvm pointer, and acquiring a kvm
> ref from within vfio while holding this spinlock, with the reference held
> until the last close for the device in question.
> 
> Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> Reported-by: Anthony Krowiak <akrowiak@linux.ibm.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---
>  drivers/vfio/group.c     | 14 +++----
>  drivers/vfio/vfio.h      |  5 ++-
>  drivers/vfio/vfio_main.c | 88
> ++++++++++++++++++++++++++++++++++++----
>  include/linux/vfio.h     |  2 +-
>  4 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index bb24b2f0271e..8f67d33e0e8d 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -164,13 +164,7 @@ static int vfio_device_group_open(struct
> vfio_device *device)
>  		goto out_unlock;
>  	}
> 
> -	/*
> -	 * Here we pass the KVM pointer with the group under the lock.  If
> the
> -	 * device driver will use it, it must obtain a reference and release it
> -	 * during close_device.
> -	 */
> -	ret = vfio_device_open(device, device->group->iommufd,
> -			       device->group->kvm);
> +	ret = vfio_device_open(device, device->group);
> 
>  out_unlock:
>  	mutex_unlock(&device->group->group_lock);
> @@ -450,6 +444,7 @@ static struct vfio_group *vfio_group_alloc(struct
> iommu_group *iommu_group,
> 
>  	refcount_set(&group->drivers, 1);
>  	mutex_init(&group->group_lock);
> +	spin_lock_init(&group->kvm_ref_lock);
>  	INIT_LIST_HEAD(&group->device_list);
>  	mutex_init(&group->device_lock);
>  	group->iommu_group = iommu_group;
> @@ -799,13 +794,14 @@
> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
>  void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
>  {
>  	struct vfio_group *group = file->private_data;
> +	unsigned long flags;
> 
>  	if (!vfio_file_is_group(file))
>  		return;
> 
> -	mutex_lock(&group->group_lock);
> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
>  	group->kvm = kvm;
> -	mutex_unlock(&group->group_lock);
> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
> 
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index f8219a438bfb..d153ad35de24 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -15,11 +15,11 @@ struct iommufd_ctx;
>  struct iommu_group;
>  struct vfio_device;
>  struct vfio_container;
> +struct vfio_group;
> 
>  void vfio_device_put_registration(struct vfio_device *device);
>  bool vfio_device_try_get_registration(struct vfio_device *device);
> -int vfio_device_open(struct vfio_device *device,
> -		     struct iommufd_ctx *iommufd, struct kvm *kvm);
> +int vfio_device_open(struct vfio_device *device, struct vfio_group
> *group);
>  void vfio_device_close(struct vfio_device *device,
>  		       struct iommufd_ctx *iommufd);
> 
> @@ -74,6 +74,7 @@ struct vfio_group {
>  	struct file			*opened_file;
>  	struct blocking_notifier_head	notifier;
>  	struct iommufd_ctx		*iommufd;
> +	spinlock_t			kvm_ref_lock;
>  };
> 
>  int vfio_device_set_group(struct vfio_device *device,
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 5177bb061b17..b0defb0d0d87 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -16,6 +16,9 @@
>  #include <linux/fs.h>
>  #include <linux/idr.h>
>  #include <linux/iommu.h>
> +#ifdef CONFIG_HAVE_KVM
> +#include <linux/kvm_host.h>
> +#endif
>  #include <linux/list.h>
>  #include <linux/miscdevice.h>
>  #include <linux/module.h>
> @@ -344,9 +347,59 @@ static bool vfio_assert_device_open(struct
> vfio_device *device)
>  	return !WARN_ON_ONCE(!READ_ONCE(device->open_count));
>  }
> 
> +#ifdef CONFIG_HAVE_KVM
> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
> +{
> +	void (*pfn)(struct kvm *kvm);
> +	bool (*fn)(struct kvm *kvm);
> +	bool ret;
> +
> +	pfn = symbol_get(kvm_put_kvm);
> +	if (WARN_ON(!pfn))
> +		return false;
> +
> +	fn = symbol_get(kvm_get_kvm_safe);
> +	if (WARN_ON(!fn)) {
> +		symbol_put(kvm_put_kvm);
> +		return false;
> +	}
> +
> +	ret = fn(kvm);
> +	if (ret)
> +		device->put_kvm = pfn;
> +	else
> +		symbol_put(kvm_put_kvm);
> +
> +	symbol_put(kvm_get_kvm_safe);
> +
> +	return ret;
> +}
> +
> +static void vfio_kvm_put_kvm(struct vfio_device *device)
> +{
> +	if (WARN_ON(!device->kvm || !device->put_kvm))
> +		return;
> +
> +	device->put_kvm(device->kvm);
> +	symbol_put(kvm_put_kvm);
> +}
> +
> +#else
> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
> *kvm)
> +{
> +	return false;
> +}
> +
> +static void vfio_kvm_put_kvm(struct vfio_device *device)
> +{
> +}
> +#endif
> +
>  static int vfio_device_first_open(struct vfio_device *device,
> -				  struct iommufd_ctx *iommufd, struct kvm
> *kvm)
> +				  struct vfio_group *group)
>  {
> +	struct iommufd_ctx *iommufd = group->iommufd;
> +	unsigned long flags;
>  	int ret;
> 
>  	lockdep_assert_held(&device->dev_set->lock);
> @@ -361,16 +414,30 @@ static int vfio_device_first_open(struct
> vfio_device *device,
>  	if (ret)
>  		goto err_module_put;
> 
> -	device->kvm = kvm;
> +	/*
> +	 * Get the KVM pointer currently associated with the group, if there
> +	 * is one, and obtain a reference now that will be held until the
> +	 * open_count reaches 0.  Save the pointer in the device for use by
> +	 * drivers.
> +	 */
> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
> +	if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
> +		device->kvm = group->kvm;
> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
> +
>  	if (device->ops->open_device) {
>  		ret = device->ops->open_device(device);
>  		if (ret)
> -			goto err_unuse_iommu;
> +			goto err_put_kvm;
>  	}
>  	return 0;
> 
> -err_unuse_iommu:
> -	device->kvm = NULL;
> +err_put_kvm:
> +	if (device->kvm) {
> +		vfio_kvm_put_kvm(device);
> +		device->put_kvm = NULL;

Can "device->put_kvm = NULL;" be part of vfio_kvm_put_kvm()?

Regards,
Yi Liu

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-01-31 20:25 ` [Intel-gfx] [PATCH] " Jason Gunthorpe
@ 2023-02-01 12:43   ` Liu, Yi L
  2023-02-01 14:42     ` Matthew Rosato
  0 siblings, 1 reply; 11+ messages in thread
From: Liu, Yi L @ 2023-02-01 12:43 UTC (permalink / raw)
  To: Jason Gunthorpe, Matthew Rosato
  Cc: akrowiak, jjherne, farman, imbrenda, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, pbonzini,
	linux-s390, borntraeger, intel-gvt-dev

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, February 1, 2023 4:26 AM
> 
> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
> > @@ -799,13 +794,14 @@
> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> >  void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> >  {
> >  	struct vfio_group *group = file->private_data;
> > +	unsigned long flags;
> >
> >  	if (!vfio_file_is_group(file))
> >  		return;
> >
> > -	mutex_lock(&group->group_lock);
> > +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
> >  	group->kvm = kvm;
> > -	mutex_unlock(&group->group_lock);
> > +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
> 
> We know we are in a sleeping context here so these are just
> 'spin_lock()', same with the other one

a dumb question. Why spinlock is required here? 😊

Regards,
Yi Liu

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-02-01  6:13 ` [Intel-gfx] [PATCH] " Tian, Kevin
@ 2023-02-01 14:27   ` Matthew Rosato
  0 siblings, 0 replies; 11+ messages in thread
From: Matthew Rosato @ 2023-02-01 14:27 UTC (permalink / raw)
  To: Tian, Kevin, alex.williamson, pbonzini, Liu, Yi L, jgg
  Cc: akrowiak, jjherne, farman, borntraeger, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, linux-s390,
	imbrenda, intel-gvt-dev

On 2/1/23 1:13 AM, Tian, Kevin wrote:
>> From: Matthew Rosato <mjrosato@linux.ibm.com>
>> Sent: Wednesday, February 1, 2023 4:07 AM
>>
>> -	device->kvm = kvm;
>> +	/*
>> +	 * Get the KVM pointer currently associated with the group, if there
>> +	 * is one, and obtain a reference now that will be held until the
>> +	 * open_count reaches 0.  Save the pointer in the device for use by
>> +	 * drivers.
>> +	 */
>> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
>> +	if (group->kvm && vfio_kvm_get_kvm_safe(device, group->kvm))
>> +		device->kvm = group->kvm;
>> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
>> +
> 
> No group reference in vfio_main.c. 

OK -- I think to do that I'll have to move the lock/unlock of the dev_set lock to group.c right before we call vfio_device_{open,close} and check open_count there to make decisions about the kvm ref (before calling vfio_device_open to decide to get kvm ref, after returning from vfio_device_open to see if we to drop ref on error, after close to see if we need to drop ref).

> 
> btw Yi, looks the deadlock issue also exists in your cdev work.
> 
> kvm_vfio_release() holds kvm lock and then try to acquire
> device->device_set->lock in vfio_device_file_set_kvm().
> 
> vfio_device_ioctl_bind_iommufd() holds device->device_set->lock
> and then call vfio_device_open() which finally hit kvm lock
> acquisition in driver's open_device routine (e.g. vfio-ap).
> 
> A similar fix is required in your series.
> 
> Thanks
> Kevin


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-02-01 12:42 ` Liu, Yi L
@ 2023-02-01 14:41   ` Matthew Rosato
  0 siblings, 0 replies; 11+ messages in thread
From: Matthew Rosato @ 2023-02-01 14:41 UTC (permalink / raw)
  To: Liu, Yi L, alex.williamson, pbonzini, jgg
  Cc: akrowiak, jjherne, farman, borntraeger, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, linux-s390,
	imbrenda, intel-gvt-dev

On 2/1/23 7:42 AM, Liu, Yi L wrote:
>> From: Matthew Rosato <mjrosato@linux.ibm.com>
...
>> +	if (device->kvm) {
>> +		vfio_kvm_put_kvm(device);
>> +		device->put_kvm = NULL;
> 
> Can "device->put_kvm = NULL;" be part of vfio_kvm_put_kvm()?

Sure


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-02-01 12:43   ` Liu, Yi L
@ 2023-02-01 14:42     ` Matthew Rosato
  2023-02-02  3:08       ` Liu, Yi L
  0 siblings, 1 reply; 11+ messages in thread
From: Matthew Rosato @ 2023-02-01 14:42 UTC (permalink / raw)
  To: Liu, Yi L, Jason Gunthorpe
  Cc: akrowiak, jjherne, farman, imbrenda, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, pbonzini,
	linux-s390, borntraeger, intel-gvt-dev

On 2/1/23 7:43 AM, Liu, Yi L wrote:
>> From: Jason Gunthorpe <jgg@nvidia.com>
>> Sent: Wednesday, February 1, 2023 4:26 AM
>>
>> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
>>> @@ -799,13 +794,14 @@
>> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
>>>  void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
>>>  {
>>>  	struct vfio_group *group = file->private_data;
>>> +	unsigned long flags;
>>>
>>>  	if (!vfio_file_is_group(file))
>>>  		return;
>>>
>>> -	mutex_lock(&group->group_lock);
>>> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
>>>  	group->kvm = kvm;
>>> -	mutex_unlock(&group->group_lock);
>>> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
>>
>> We know we are in a sleeping context here so these are just
>> 'spin_lock()', same with the other one
> 
> a dumb question. Why spinlock is required here? 😊
> 

You mean as opposed to another mutex?  I don't think it's required per se (we are replacing a mutex so we could have again used another mutex here), but all current users of this new lock hold it over a very short window (e.g. set a pointer as above, or refcount++ and copy the pointer as in the first device_open)


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock
  2023-02-01 14:42     ` Matthew Rosato
@ 2023-02-02  3:08       ` Liu, Yi L
  0 siblings, 0 replies; 11+ messages in thread
From: Liu, Yi L @ 2023-02-02  3:08 UTC (permalink / raw)
  To: Matthew Rosato, Jason Gunthorpe
  Cc: akrowiak, jjherne, farman, imbrenda, frankja, pmorel, david,
	Christopherson, ,
	Sean, intel-gfx, cohuck, linux-kernel, pasic, kvm, pbonzini,
	linux-s390, borntraeger, intel-gvt-dev

> From: Matthew Rosato <mjrosato@linux.ibm.com>
> Sent: Wednesday, February 1, 2023 10:43 PM
> 
> On 2/1/23 7:43 AM, Liu, Yi L wrote:
> >> From: Jason Gunthorpe <jgg@nvidia.com>
> >> Sent: Wednesday, February 1, 2023 4:26 AM
> >>
> >> On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote:
> >>> @@ -799,13 +794,14 @@
> >> EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> >>>  void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> >>>  {
> >>>  	struct vfio_group *group = file->private_data;
> >>> +	unsigned long flags;
> >>>
> >>>  	if (!vfio_file_is_group(file))
> >>>  		return;
> >>>
> >>> -	mutex_lock(&group->group_lock);
> >>> +	spin_lock_irqsave(&group->kvm_ref_lock, flags);
> >>>  	group->kvm = kvm;
> >>> -	mutex_unlock(&group->group_lock);
> >>> +	spin_unlock_irqrestore(&group->kvm_ref_lock, flags);
> >>
> >> We know we are in a sleeping context here so these are just
> >> 'spin_lock()', same with the other one
> >
> > a dumb question. Why spinlock is required here? 😊
> >
> 
> You mean as opposed to another mutex?  I don't think it's required per se
> (we are replacing a mutex so we could have again used another mutex
> here), but all current users of this new lock hold it over a very short window
> (e.g. set a pointer as above, or refcount++ and copy the pointer as in the
> first device_open)

I see. Just not sure if spinlock is required for a special reason.

Regards,
Yi Liu

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-02-02  3:09 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-31 20:06 [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock Matthew Rosato
2023-01-31 20:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-01-31 20:25 ` [Intel-gfx] [PATCH] " Jason Gunthorpe
2023-02-01 12:43   ` Liu, Yi L
2023-02-01 14:42     ` Matthew Rosato
2023-02-02  3:08       ` Liu, Yi L
2023-01-31 20:47 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2023-02-01  6:13 ` [Intel-gfx] [PATCH] " Tian, Kevin
2023-02-01 14:27   ` Matthew Rosato
2023-02-01 12:42 ` Liu, Yi L
2023-02-01 14:41   ` Matthew Rosato

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).