On Mon, Aug 18, 2025 at 11:39:49AM -0300, Jason Gunthorpe wrote:
> On Mon, Aug 11, 2025 at 03:59:10PM -0700, Nicolin Chen wrote:
>
> > Introduce a new iommu_get_domain_for_dev_locked() helper to be used by
> > those drivers in a context that is already under the protection of the
> > group->mutex, e.g. those attach_dev callback functions. And roll out the
> > new helper to all the existing IOMMU drivers.
>
> I still don't much care for this, I think it would be better to
> approach this problem by passing the old domain to the driver callback:
Hmm, that was my first attempt before making this patch until...
> > @@ -390,7 +390,7 @@ static int qcom_iommu_attach_dev(struct iommu_domain *domain, struct device *dev
> > static int qcom_iommu_identity_attach(struct iommu_domain *identity_domain,
> > struct device *dev)
> > {
> > - struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> > + struct iommu_domain *domain = iommu_get_domain_for_dev_locked(dev);
>
> Because this is a very common pattern in drivers.
>
> Once that is done we can see what calls to iommu_get_domain_for_dev()
> are even left,
... I found that in SMMUv3 driver, iommu_get_domain_for_dev() is
used to get the RID domain for an SVA domain:
arm_smmu_set_pasid()
arm_smmu_blocking_set_dev_pasid()
These two are already given an "old" (SVA) domain pointer, FWIW.
So, we may change to passing in the old domain as you suggested,
yet we still have to fix the iommu_get_domain_for_dev() in order
to reflect the RID domain correctly for the driver that calls it
(or even potentially) in some group->mutex locked context where
the RID domain might not be naturally passed in.
> arguably we should be trying to eliminate this badly
> locked thing...
Any suggestion?
I see it inevitable that such an iommu specific flag per-device
would have to take the lock..
Thanks
Nicolin
