| Message ID | 3-v6-228e7adf25eb+4155-smmuv3_newapi_p2_jgg@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Update SMMUv3 to the modern iommu API (part 2/3) | expand |
Hi Jason, On Wed, Mar 27, 2024 at 03:07:49PM -0300, Jason Gunthorpe wrote: > The SVA code is wired to assume that the SVA is programmed onto the > mm->pasid. The current core code always does this, so it is fine. > > Add a check for clarity. > > Fixes: 386fa64fd52b ("arm-smmu-v3/sva: Add SVA domain support") > Tested-by: Nicolin Chen <nicolinc@nvidia.com> > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> > Reviewed-by: Mostafa Saleh <smostafa@google.com> I think there might have been a mix up, this was patch 01 in v5, I didn’t add a tag on it. I don’t have a problem with the patch. I just think (based on my limited understanding and rules in[1]) that it is not a fix as (mentioned in the last thread) the only caller in the tree calls it properly. But that’s up to the driver/stable maintainers. [1] https://www.kernel.org/doc/html/next/process/stable-kernel-rules.html > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > index 2cd433a9c8a0fa..41b44baef15e80 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > @@ -569,6 +569,9 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain, > int ret = 0; > struct mm_struct *mm = domain->mm; > > + if (mm_get_enqcmd_pasid(mm) != id) > + return -EINVAL; > + > mutex_lock(&sva_lock); > ret = __arm_smmu_sva_bind(dev, id, mm); > mutex_unlock(&sva_lock); > -- > 2.43.2 > Thanks, Mostafa
On Thu, Mar 28, 2024 at 01:18:10PM +0000, Mostafa Saleh wrote: > Hi Jason, > > On Wed, Mar 27, 2024 at 03:07:49PM -0300, Jason Gunthorpe wrote: > > The SVA code is wired to assume that the SVA is programmed onto the > > mm->pasid. The current core code always does this, so it is fine. > > > > Add a check for clarity. > > > > Fixes: 386fa64fd52b ("arm-smmu-v3/sva: Add SVA domain support") > > Tested-by: Nicolin Chen <nicolinc@nvidia.com> > > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> > > Reviewed-by: Mostafa Saleh <smostafa@google.com> > > I think there might have been a mix up, this was patch 01 in v5, > I didn’t add a tag on it. I don’t have a problem with the patch. Oh yes, it is somehow my mistake, sorry. All this tag annotation is done by hand :( I also didn't intend to re-send the first two patches, they are going to be in rc3. Jason
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c index 2cd433a9c8a0fa..41b44baef15e80 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c @@ -569,6 +569,9 @@ static int arm_smmu_sva_set_dev_pasid(struct iommu_domain *domain, int ret = 0; struct mm_struct *mm = domain->mm; + if (mm_get_enqcmd_pasid(mm) != id) + return -EINVAL; + mutex_lock(&sva_lock); ret = __arm_smmu_sva_bind(dev, id, mm); mutex_unlock(&sva_lock);
The SVA code is wired to assume that the SVA is programmed onto the mm->pasid. The current core code always does this, so it is fine. Add a check for clarity. Fixes: 386fa64fd52b ("arm-smmu-v3/sva: Add SVA domain support") Tested-by: Nicolin Chen <nicolinc@nvidia.com> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +++ 1 file changed, 3 insertions(+)