On Tue, Mar 10, 2026 at 01:51:24PM +0530, Nilay Shroff wrote:
> Commit a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev()
> helper") introduced iommu_driver_get_domain_for_dev() for driver
> code paths that hold iommu_group->mutex while attaching a device
> to an IOMMU domain.
> 
> The same commit also added a lockdep assertion in
> iommu_get_domain_for_dev() to ensure that callers do not hold
> iommu_group->mutex when invoking it.
> 
> On powerpc platforms, when PCI device ownership is switched from
> BLOCKED to the PLATFORM domain, the attach callback
> spapr_tce_platform_iommu_attach_dev() still calls
> iommu_get_domain_for_dev(). This happens while iommu_group->mutex
> is held during domain switching, which triggers the lockdep warning
> below during PCI enumeration:
> 
> WARNING: drivers/iommu/iommu.c:2252 at iommu_get_domain_for_dev+0x38/0x80, 
> CPU#2: swapper/0/1
> Modules linked in:
> CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc2+ #35 PREEMPT
> Hardware name: IBM,9105-22A Power11 (architected) 0x820200 0xf000007 
> of:IBM,FW1120.00 (RB1120_115) hv:phyp pSeries
> NIP:  c000000000c244c4 LR: c00000000005b5a4 CTR: c00000000005b578
> REGS: c00000000a7bf280 TRAP: 0700   Not tainted  (7.0.0-rc2+)
> MSR:  8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 22004422  XER: 0000000a
> CFAR: c000000000c24508 IRQMASK: 0
> GPR00: c00000000005b5a4 c00000000a7bf520 c000000001dc8100 0000000000000001
> GPR04: c00000000f972f10 0000000000000000 0000000000000000 0000000000000001
> GPR08: 0000001ffbc60000 0000000000000001 0000000000000000 0000000000000000
> GPR12: c00000000005b578 c000001fffffe480 c000000000011618 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: ffffffffffffefff 0000000000000000 c000000002d30eb0 0000000000000001
> GPR24: c0000000017881f8 0000000000000000 0000000000000001 c00000000f972e00
> GPR28: c00000000bbba0d0 0000000000000000 c00000000bbba0d0 c00000000f972e00
> NIP [c000000000c244c4] iommu_get_domain_for_dev+0x38/0x80
> LR [c00000000005b5a4] spapr_tce_platform_iommu_attach_dev+0x2c/0x98
> Call Trace:
>  iommu_get_domain_for_dev+0x68/0x80 (unreliable)
>  spapr_tce_platform_iommu_attach_dev+0x2c/0x98
>  __iommu_attach_device+0x44/0x220
>  __iommu_device_set_domain+0xf4/0x194
>  __iommu_group_set_domain_internal+0xec/0x228
>  iommu_setup_default_domain+0x5f4/0x6a4
>  __iommu_probe_device+0x674/0x724
>  iommu_probe_device+0x50/0xb4
>  iommu_add_device+0x48/0x198
>  pci_dma_dev_setup_pSeriesLP+0x198/0x4f0
>  pcibios_bus_add_device+0x80/0x464
>  pci_bus_add_device+0x40/0x100
>  pci_bus_add_devices+0x54/0xb0
>  pcibios_init+0xd8/0x140
>  do_one_initcall+0x8c/0x598
>  kernel_init_freeable+0x3ec/0x850
>  kernel_init+0x34/0x270
>  ret_from_kernel_user_thread+0x14/0x1c
> 
> Fix this by using iommu_driver_get_domain_for_dev() instead of
> iommu_get_domain_for_dev() in spapr_tce_platform_iommu_attach_dev(),
> which is the appropriate helper for callers holding the group mutex.
> 
> Cc: [email protected]
> Fixes: a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev() helper")
> Signed-off-by: Nilay Shroff <[email protected]>
 
Reviewed-by: Nicolin Chen <[email protected]>

Reply via email to