> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Wednesday, August 9, 2023 10:44 PM
>
> When bus_iommu_probe() runs it can attempt to probe the iommu itself, for
> instance if the iommu is located on a platform_bus. This will cause the
> device_lock() to deadlock on itself as the device_driver probe() callback
> for the device calling iommu_device_register() already holds the
> device_lock():
>
> probe_iommu_group+0x18/0x38
> bus_for_each_dev+0xe4/0x168
> bus_iommu_probe+0x8c/0x240
> iommu_device_register+0x120/0x1b0
> mtk_iommu_probe+0x494/0x7a0
> platform_probe+0x94/0x100
> really_probe+0x1e4/0x3e8
> __driver_probe_device+0xc0/0x1a0
> driver_probe_device+0x110/0x1f0
> __device_attach_driver+0xf0/0x1b0
> bus_for_each_drv+0xf0/0x170
> __device_attach+0x120/0x240
> device_initial_probe+0x1c/0x30
> bus_probe_device+0xdc/0xe8
> deferred_probe_work_func+0xf0/0x140
> process_one_work+0x3b0/0x910
> worker_thread+0x33c/0x610
> kthread+0x1dc/0x1f0
> ret_from_fork+0x10/0x20
>
> Keep track of the iommu itself and do not attempt to relock the device
> while doing the probe_iommu_group scan.
>
> To accommodate omap's use of unregistered struct iommu_device's add a
> new
> 'hwdev' member to keep track of the hwdev in all cases. Normally this
> would be dev->parent, but since omap doesn't allocate that struct it won't
> exist for it.
>
> Fixes: a16b5d1681ab ("iommu: Complete the locking for dev-
> >iommu_group")
> Reported-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx>
> Closes: https://lore.kernel.org/linux-iommu/CAGXv+5E-
> f9AteAYkmXYzVDZFSA_royc7-bS5LcrzzuHDnXccwA@xxxxxxxxxxxxxx
> Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> Tested-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx>
> Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
