* [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).