From: Jason Gunthorpe <jgg@nvidia.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Joerg Roedel <jroedel@suse.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Kevin Tian <kevin.tian@intel.com>,
Chen-Yu Tsai <wenst@chromium.org>
Subject: Re: [PATCH v2 0/4] Fix device_lock deadlock on two probe() paths
Date: Fri, 18 Aug 2023 15:15:46 -0300 [thread overview]
Message-ID: <ZN+1UktCwqTu53FI@nvidia.com> (raw)
In-Reply-To: <bff750f47b326c7c0066f1debc5411a8208a128c.camel@linux.ibm.com>
On Fri, Aug 18, 2023 at 02:00:21PM -0400, Eric Farman wrote:
> Well, I'm trying to chase down an apparent deadlock in the mdev cases
> that is introduced with the commit [1] blamed by these fixes. Seems
> that when iommu_group_{add|remove}_device gets called out of vfio (for
> example, vfio-ap or -ccw), the device lock is already held so
> attempting to get it again isn't going to go well.
Oh, yes. Thankfully due to all the recent cleanup there is now only
one caller of iommu_group_add_device() - VFIO and only on the
vfio_register_emulated_iommu_dev() path.
All those callers are under mdev probe callbacks so they all must have
the device lock held. iommu_group_remove_device is the same. Simple
fix to just assert the device lock is held.
> I'm puzzled why lockdep isn't shouting over this for me, so I added a
> lockdep_assert_not_held() in those paths to get a proper callchain:
The driver core mostly disables lockdep on the device_lock() :(
Does this work for you?
Thanks,
Jason
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 18162049bd2294..1f58bfacb47951 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1166,12 +1166,11 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
{
struct group_device *gdev;
- device_lock(dev);
+ device_lock_assert(dev);
+
gdev = iommu_group_alloc_device(group, dev);
- if (IS_ERR(gdev)) {
- device_unlock(dev);
+ if (IS_ERR(gdev))
return PTR_ERR(gdev);
- }
iommu_group_ref_get(group);
dev->iommu_group = group;
@@ -1179,7 +1178,6 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
mutex_lock(&group->mutex);
list_add_tail(&gdev->list, &group->devices);
mutex_unlock(&group->mutex);
- device_unlock(dev);
return 0;
}
EXPORT_SYMBOL_GPL(iommu_group_add_device);
@@ -1195,14 +1193,13 @@ void iommu_group_remove_device(struct device *dev)
{
struct iommu_group *group;
- device_lock(dev);
+ device_lock_assert(dev);
+
group = dev->iommu_group;
if (group) {
dev_info(dev, "Removing from iommu group %d\n", group->id);
__iommu_group_remove_device(dev);
}
- device_unlock(dev);
-
}
EXPORT_SYMBOL_GPL(iommu_group_remove_device);
next prev parent reply other threads:[~2023-08-18 18:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230809144403eucas1p1345aec6ec34440f1794594426e0402ab@eucas1p1.samsung.com>
2023-08-09 14:43 ` [PATCH v2 0/4] Fix device_lock deadlock on two probe() paths Jason Gunthorpe
2023-08-09 14:43 ` [PATCH v2 1/4] iommu: Provide iommu_probe_device_locked() Jason Gunthorpe
2023-08-09 14:43 ` [PATCH v2 2/4] iommu: Pass in the iommu_device to probe for in bus_iommu_probe() Jason Gunthorpe
2023-08-09 14:43 ` [PATCH v2 3/4] iommu: Do not attempt to re-lock the iommu device when probing Jason Gunthorpe
2023-08-10 2:37 ` Tian, Kevin
2023-08-09 14:43 ` [PATCH v2 4/4] iommu: dev->iommu->iommu_dev must be set before ops->device_group() Jason Gunthorpe
2023-08-10 2:37 ` Tian, Kevin
2023-08-09 15:49 ` [PATCH v2 0/4] Fix device_lock deadlock on two probe() paths Joerg Roedel
2023-08-09 15:55 ` Jason Gunthorpe
2023-08-10 16:15 ` Jeffrey Hugo
2023-08-17 8:31 ` Marek Szyprowski
2023-08-17 18:33 ` Jason Gunthorpe
2023-08-18 15:56 ` Joerg Roedel
2023-08-18 16:06 ` Jason Gunthorpe
2023-08-18 18:00 ` Eric Farman
2023-08-18 18:15 ` Jason Gunthorpe [this message]
2023-08-18 18:32 ` Eric Farman
2023-08-18 18:24 ` Joerg Roedel
2023-08-18 18:50 ` Robin Murphy
2023-08-18 19:19 ` Jason Gunthorpe
2023-08-21 11:35 ` Robin Murphy
2023-08-18 19:18 ` Jason Gunthorpe
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=ZN+1UktCwqTu53FI@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=farman@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=wenst@chromium.org \
--cc=will@kernel.org \
/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.