UPSTREAM: iommu: Handle race with default domain setup
It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. Reported-by:Charan Teja Kalla <quic_charante@quicinc.com> Fixes: 98ac73f9 ("iommu: Require a default_domain for all iommu drivers") Reviewed-by:
Jason Gunthorpe <jgg@nvidia.com> Change-Id: Ie291231b7d8add11b87995c725691d546793ae9d Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.1740753261.git.robin.murphy@arm.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> (cherry picked from commit b46064a1) Bug: 422127969 Bug: 422706930 Signed-off-by:
liuqi <liuqi20328@gmail.com> (cherry picked from commit c1b974e5)
Loading
Please register or sign in to comment