On Fri, May 15, 2020 at 05:28:53PM +0100, Robin Murphy wrote:
> On 2020-05-15 17:14, Joerg Roedel wrote:
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index ba128d1cdaee..403fda04ea98 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -362,8 +362,8 @@ static int iommu_dma_deferred_attach(struct device *dev,
> > return 0;
> > if (unlikely(ops->is_attach_deferred &&
> > - ops->is_attach_deferred(domain, dev)))
> > - return iommu_attach_device(domain, dev);
> > + ops->is_attach_deferred(domain, dev)))
> > + return iommu_attach_device_no_defer(domain, dev);
>
> Wouldn't it be simpler to just invoke ops->attach_dev directly and avoid
> having to formalise a public interface that nobody else should ever use
> anyway?
That would omit the ops->attach_dev != NULL check and the trace-point on
device attach. Besides that, it would be a layering violation. But the
function is of course entirely internal to the iommu subsytem and is a
good canditate to be moved to a header file in drivers/iommu.
> @@ -746,8 +747,11 @@ int iommu_group_add_device(struct iommu_group *group,
> struct device *dev)
>
> mutex_lock(&group->mutex);
> list_add_tail(&device->list, &group->devices);
> - if (group->domain)
> - ret = __iommu_attach_device(group->domain, dev);
> + domain = group->domain;
> + if (domain && (!domain->ops->is_attach_deferred ||
> + !domain->ops->is_attach_deferred(domain, dev)))
> + ret = __iommu_attach_device(domain, dev);
> + }
> mutex_unlock(&group->mutex);
> if (ret)
> goto err_put_group;
No, doing this in iommu_group_add_device() doesn't solve the problem.
The attach must not happen before a device driver took control of the
device and silenced any DMA initiated by the old kernel. At probe time
this isn't guaranteed.
Joerg
