Re: [revert commit 83b3836bf83f09beea5f592b126cfdd1bc921e48] [mainline] [6.8.0-rc3]kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Feb 07, 2024 at 09:53:30PM +0530, Venkat Rao Bagalkote wrote:
>    Greetings!!!
> 
>    [revert commit 83b3836bf83f09beea5f592b126cfdd1bc921e48] [mainline]
>    [6.8.0-rc3]kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!
> 
>    Reverting below commit id issue is not seen.
> 83b3836bf83f09beea5f592b126cfdd1bc921e48
>      iommu: Allow ops->default_domain to work when !CONFIG_IOMMU_DMA

Well, you'll get probing failures if you revert it, so this seems like
a false bisection.. Though no doubt it will land on one of the earlier
iommu patches.

> [ 7843.149112] NIP [c0000000000ff4d4] iommu_reconfig_notifier+0x94/0x200
> [ 7843.149123] LR [c0000000000ff4cc] iommu_reconfig_notifier+0x8c/0x200
> [ 7843.149129] Call Trace:
> [ 7843.149131] [c0000013aed5fae0] [c0000000000ff4cc] iommu_reconfig_notifier+0x8
> c/0x200 (unreliable)
> [ 7843.149138] [c0000013aed5fb10] [c0000000001a27b0] notifier_call_chain+0xb8/0x
> 19c
> [ 7843.149146] [c0000013aed5fb70] [c0000000001a2a78] blocking_notifier_call_chai
> n+0x64/0x98
> [ 7843.149152] [c0000013aed5fbb0] [c000000000c4a898] of_reconfig_notify+0x44/0xd
> c
> [ 7843.149160] [c0000013aed5fc20] [c000000000c4add4] of_detach_node+0x78/0xb0
> [ 7843.149165] [c0000013aed5fc70] [c0000000000f96a8] ofdt_write.part.0+0x86c/0xb
> b8
> [ 7843.149171] [c0000013aed5fce0] [c00000000069b4bc] proc_reg_write+0xf4/0x150
> [ 7843.149178] [c0000013aed5fd10] [c0000000005bfeb4] vfs_write+0xf8/0x488
> [ 7843.149184] [c0000013aed5fdc0] [c0000000005c0570] ksys_write+0x84/0x140
> [ 7843.149189] [c0000013aed5fe10] [c000000000033358] system_call_exception+0x138
> /0x330
> [ 7843.149196] [c0000013aed5fe50] [c00000000000d05c] system_call_vectored_common
> +0x15c/0x2ec

What is all this?

Why is it reaching into the iommu space and messing it up from a
notifier and then crashing when it is not in the state it expects?

If a DT property is being removed shouldn't that be achieved by
removing the device first and letting the normal iommu driver release
flow run?

I have no idea what this is doing, but it looks sketchy :\

Shivaprasad/Ovidiu can you look at this? It looks like some case with
hot device removal?

Thanks,
Jason