Re: [PATCH] iommu: Don't let a driver bind while bus_iommu_probe() still probes its device

[Robin Murphy <robin.murphy@arm.com>]

On 2026-11-12 5:32 pm, Arun Iyengar wrote:
> Please don't apply v1, and it should not go to stable. On re-reading
> I found three problems:
> 
> 1. "A fwspec without a group means a probe is in progress" does not
>     hold on ACPI. On the driver bind path acpi_iommu_configure_id()
>     creates a fwspec, and nothing there probes the device or frees the
>     fwspec. So a device whose IOMMU probe failed earlier would get
>     -EPROBE_DEFER from iommu_device_use_default_domain() on every bind
>     attempt, where today it binds without the IOMMU. OF does not have
>     this, because of_iommu_configure() either probes or frees.
> 
> 2. Drivers with driver_managed_dma never call
>     iommu_device_use_default_domain(), so the window stays open for
>     them (e.g. pcieport with a modular IOMMU driver), and the changed
>     WARN condition can then hide it.
> 
> 3. Replaying dma_configure for a device whose driver is inside probe()
>     is wider than I described. It applies to every such device on the
>     bus that has no group yet, including a client that went ahead
>     without its IOMMU after the deferred probe timeout; that client
>     would get its group and default domain while its driver is probing,
>     without a warning.
> 
> The race itself is as in the commit message: the client's dma_configure
> sees the dev->iommu or fwspec of a concurrent bus_iommu_probe() replay
> while iommu_probe_device_lock is dropped.
> 
> For v2 I intend to mark the in-progress probe explicitly in dev->iommu,
> have of_iommu_configure() and acpi_iommu_configure_id() defer any caller
> other than the replay while the mark is set, and leave the replay
> condition and iommu_device_use_default_domain() alone. The other
> ordering in the commit message (the client sets dev->driver before the
> replay check) would then still warn, although nothing is wrong there
> besides the warning; I would look at that separately. If you would
> rather see this solved another way, please say so.
> 
> Tudor: you are on Cc because this is the same "!dev->iommu" gate on the
> readiness check as in your thread
> <20260323-iommu-ready-check-v1-1-5f6fef8f9f59@linaro.org>, for a
> different case (one IOMMU, concurrent bind).

Really the dev->driver checks are less than ideal, as they're inherently 
racy with an unavoidable false-positive window. What we could really do 
with - which might now be viable with the recent atomic device flags - 
is a specific indicator that a device has got far enough into binding a 
driver to be past the point of waiting or an IOMMU. The 
BUS_NOTIFY_BIND_DRIVER call is in fact in more or less the right place 
for that, so we could potentially do the flag management from 
iommu_bus_notifier() rather than clutter up the driver core with yet 
more hooks, but the flag itself can't be in dev->iommu, since its whole 
meaning is "we assumed this device didn't have an IOMMU and now it's too 
late to safely change that".

Thanks,
Robin.