On 8/9/2023 8:43 AM, Jason Gunthorpe wrote:
I missed two paths where __iommu_probe_device() can be called while
already holding the device_lock() for the device that is to be probed.
This causes a deadlock because __iommu_probe_device() will attempt to
re-acquire the lock.
Organize things so that these two paths can re-use the existing already
held device_lock by marking the call chains based on if the lock is held
or not.
Also the order of iommu_init_device() was not correct for
generic_single_device_group()
v2:
- New patch to correct the order of setting iommu_dev during
iommu_init_device()
- Spelling fixes
- Simply block probing the iommu device itself instead of trying to do it
v1: https://lore.kernel.org/r/0-v1-8612b9ef48da+333-iommu_group_locking2_jgg@xxxxxxxxxx
Jason Gunthorpe (4):
iommu: Provide iommu_probe_device_locked()
iommu: Pass in the iommu_device to probe for in bus_iommu_probe()
iommu: Do not attempt to re-lock the iommu device when probing
iommu: dev->iommu->iommu_dev must be set before ops->device_group()
drivers/acpi/scan.c | 5 +--
drivers/iommu/iommu.c | 65 +++++++++++++++++++++++++++-----------
drivers/iommu/of_iommu.c | 2 +-
drivers/iommu/omap-iommu.c | 12 +++++--
include/linux/iommu.h | 6 +++-
5 files changed, 65 insertions(+), 25 deletions(-)
base-commit: 8d3740021d5d461e1ec4c17fc5625b9b4237c2f8
I found that -next broke boot on the Lenovo Miix 630 laptop (Qualcomm
MSM8998). Bisected to "iommu: Complete the locking for dev->iommu_group".
I applied this series and the boot hang failure shortly after iommu
probe goes away.
Tested-by: Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx>
