On Wed, Apr 23, 2025 at 10:31:16AM -0700, William McVicker wrote: > On 04/22/2025, Jason Gunthorpe wrote: > > On Tue, Apr 22, 2025 at 02:55:28PM -0700, William McVicker wrote: > > > > > On this note, I was looking through `of_dma_configure_id()` and am also > > > wondering if we may hit other race conditions if the device is still being > > > probed and the dma properties (like the coherent dma mask) haven't been fully > > > populated? Just checking if the driver is bound, doesn't seem like enough to > > > start configuring the DMA when async probing can happen. > > > > I think the reasoning at work here is that the plugin path for a > > struct device should synchronously setup the iommu. > > > > There is enough locking there that the iommu code won't allow the > > device plugin to continue until the iommu is fully setup under the > > global lock. > > > > The trick of using dev->driver is only a way to tell if this function > > is being called from the driver plugin path just before starting the > > driver, or from the iommu code just before configuring the iommu. > > > > Given that explanation can you see issues with of_dma_configure_id() ? > > > > Jason > > I think the only concern is when a driver calls dma_set_mask_and_coherent() in > it's probe function. If we can handle that case in an asynchrounous manner, > then I think we are good. You should never get to a driver probe function while iommu setup is still concurrently running. That would be a major bug and break alot of stuff. Jason
