[ARM IOMMU] IOMMU framework concurrency issue

Jason Gunthorpe jgg at ziepe.ca
Thu Oct 19 08:15:09 PDT 2023


On Thu, Oct 19, 2023 at 04:21:47PM +0800, Zhenhua Huang wrote:
> In above time window (1), dev->iommu allocated but not freed, if it's just
> accessed by client device's probing(Thread 1)..     crash happens.
> 
> I also want to mention from our side, it's *not only seen for non-iommu*
> device.

I see. So there are only two locks we currently have that could
resolve that - the device_lock or the iommu_probe_device_lock

The device_lock path is what my prior series did, in your case you
already have the device_lock on of_dma_configure_id() so you just need
it on the bus path.

The iommu_probe_device_lock is what I guess Robin was thinking of with
the of_xlate rework.. I looked a little and it seems like quite a
thorny problem.. The ARM SMMU drivers seem to model the correct design
using the iommu_fwspec to pass data from of_xlate to probe, while a
whole bunch of other drivers decided to put the first half of their
probe functions into of_xlate!

To untangle this to use the iommu_probe_device_lock the of_xlate would
have to stop using the struct dev (ie so it cannot touch the
dev->iommu any more) and all the dev->iommu touches in the of/acpi
code reorganized into function arguments to iommu_probe which would
then store them into the dev->iommu under the lock. Ie stop using
dev->iommu as some temporary scratch pad to shuffle data around prior
to probing. Pass iommu_fwspec as an arg to iommu_probe and a new
ops->probe_fwspec. Stop calling dev_iommu_priv_set from of_xlate ops.

> Patch seems good to me and in theory can cover the case I have met. I tested
> below based on 6.6-rc1 for sanity with minor changes(clean up tags etc). If
> you're OK I want to propagate into our tree and to see if it fixes issue?

I don't think this patch can solve the races with of_xlate vs probe,
that is just wrongly locked.

I assume my series you linked to comprehensively fixes this?

FWIW I don't have the energy to try and fix all the wonky drivers
properly so I don't plan to revisit it.

Jason



More information about the linux-arm-kernel mailing list