> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Monday, September 27, 2021 11:09 PM
>
> On Mon, Sep 27, 2021 at 09:42:58AM +0000, Tian, Kevin wrote:
>
> > +static int iommu_dev_viable(struct device *dev, void *data)
> > +{
> > + enum dma_hint hint = *data;
> > + struct device_driver *drv = READ_ONCE(dev->driver);
> > +
> > + /* no conflict if the new device doesn't do DMA */
> > + if (hint == DMA_FOR_NONE)
> > + return 0;
> > +
> > + /* no conflict if this device is driver-less, or doesn't do DMA */
> > + if (!drv || (drv->dma_hint == DMA_FOR_NONE))
> > + return 0;
>
> While it is kind of clever to fetch this in the drv like this, the
> locking just doesn't work right.
>
> The group itself needs to have an atomic that encodes what state it is
> in. You can read the initial state from the drv, under the
> device_lock, and update the atomic state
will do.
>
> Also, don't call it "hint", there is nothing hinty about this, it has
> definitive functional impacts.
possibly dma_mode (too broad?) or dma_usage
>
> Greg will want to see a definiate benefit from this extra global code,
> so be sure to explain about why the BUG_ON is bad, and how driver core
> involvement is needed to fix it properly.
>
Sure. and I plan to at least have the patches aligned in this loop first,
before rolling up to Greg. Better we all confirm it's the right approach
with all corner cases covered and then involve Greg to help judge
a clean driver core change. 😊
Thanks
Kevin
