[v5,5/6] iommu: Support mm PASID 1:n with sva domains

  Each mm bound to devices gets a PASID and corresponding sva domains
allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
field of the mm. The PASID is released in __mmdrop(), while a sva domain
is released when no one is using it (the reference count is decremented
in iommu_sva_unbind_device()). However, although sva domains and their
PASID are separate objects such that their own life cycles could be
handled independently, an enqcmd use case may require releasing the
PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
will be permanently used by the mm and won't be released until the end
of mm) and only allows to drop the PASID after the sva domains are
released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
increment the mm reference count and mmdrop() is invoked in
iommu_domain_free() to decrement the mm reference count.

Since the required info of PASID and sva domains is kept in struct
iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
field in mm struct. The sva domain list is protected by iommu_sva_lock.

Besides, this patch removes mm_pasid_init(), as with the introduced
iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
---

Change in v5:
- Use smp_store_release() & READ_ONCE() in storing and loading mm's
  pasid value.

Change in v4:
- Rebase to v6.6-rc1.

 drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
 include/linux/iommu.h     | 18 +++++++++++-------
 kernel/fork.c             |  1 -
 3 files changed, 39 insertions(+), 20 deletions(-)
  

On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
> 
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
> 
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> 
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
> 
> Change in v5:
> - Use smp_store_release() & READ_ONCE() in storing and loading mm's
>   pasid value.
> 
> Change in v4:
> - Rebase to v6.6-rc1.
> 
>  drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
>  include/linux/iommu.h     | 18 +++++++++++-------
>  kernel/fork.c             |  1 -
>  3 files changed, 39 insertions(+), 20 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason
  

Hi Tina,

On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:

> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
> 
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
> 
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> 
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>

> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
>         struct device *dev = handle->dev;
> 
>         mutex_lock(&iommu_sva_lock);
> +       iommu_detach_device_pasid(domain, dev, pasid);
>         if (--domain->users == 0) {
> -               iommu_detach_device_pasid(domain, dev, pasid);
> +               list_del(&domain->next);
>                 iommu_domain_free(domain);
>         }
>         mutex_unlock(&iommu_sva_lock);
> @@ -209,4 +224,5 @@ void mm_pasid_drop(struct mm_struct *mm)
>                 return;
> 
>         iommu_free_global_pasid(mm_get_pasid(mm));
> +       kfree(mm->iommu_mm);

I ran some SVA tests by applying this series on top of my local
SMMUv3 tree, though it is not exactly a vanilla mainline tree.
And I see a WARN_ON introduced by this patch (did git-bisect):

[  364.237319] ------------[ cut here ]------------
[  364.237328] ida_free called for id=12 which is not allocated.
[  364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525 ida_free+0x10c/0x1d0
....
[  364.237415] pc : ida_free+0x10c/0x1d0
[  364.237416] lr : ida_free+0x10c/0x1d0
....
[  364.237439] Call trace:
[  364.237440]  ida_free+0x10c/0x1d0
[  364.237442]  iommu_free_global_pasid+0x30/0x50
[  364.237449]  mm_pasid_drop+0x44/0x70
[  364.237452]  __mmdrop+0xf4/0x210
[  364.237457]  finish_task_switch.isra.0+0x238/0x2e8
[  364.237460]  schedule_tail+0x1c/0x1b8
[  364.237462]  ret_from_fork+0x4/0x20
[  364.237466] irq event stamp: 0
[  364.237467] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
[  364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
[  364.237473] softirqs last  enabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
[  364.237475] softirqs last disabled at (0): [<0000000000000000>] 0x0
[  364.237476] ---[ end trace 0000000000000000 ]---

I haven't traced it closely to see what's wrong, due to some other
tasks. Yet, if you have some idea about this or something that you
want me to try, let me know.

Thanks
Nicolin
  

On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> Each mm bound to devices gets a PASID and corresponding sva domains
> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
> field of the mm. The PASID is released in __mmdrop(), while a sva domain
> is released when no one is using it (the reference count is decremented
> in iommu_sva_unbind_device()). However, although sva domains and their
> PASID are separate objects such that their own life cycles could be
> handled independently, an enqcmd use case may require releasing the
> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
> will be permanently used by the mm and won't be released until the end
> of mm) and only allows to drop the PASID after the sva domains are
> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
> increment the mm reference count and mmdrop() is invoked in
> iommu_domain_free() to decrement the mm reference count.
> 
> Since the required info of PASID and sva domains is kept in struct
> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
> field in mm struct. The sva domain list is protected by iommu_sva_lock.
> 
> Besides, this patch removes mm_pasid_init(), as with the introduced
> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> 
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> ---
> 
> Change in v5:
> - Use smp_store_release() & READ_ONCE() in storing and loading mm's
>   pasid value.
> 
> Change in v4:
> - Rebase to v6.6-rc1.
> 
>  drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++------------
>  include/linux/iommu.h     | 18 +++++++++++-------
>  kernel/fork.c             |  1 -
>  3 files changed, 39 insertions(+), 20 deletions(-)

I was wondering what Nicolin's issue was, didn't see anything.

But I think you should incorporate this into the patch.

And there is a straightforward way to move the global lock into the
iommu_mm_data that we can explore later.

diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index b2c1db1ae385b0..e712554ea3656f 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -12,34 +12,33 @@
 static DEFINE_MUTEX(iommu_sva_lock);
 
 /* Allocate a PASID for the mm within range (inclusive) */
-static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
+static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
+						 struct device *dev)
 {
-	ioasid_t pasid;
 	struct iommu_mm_data *iommu_mm;
-	int ret = 0;
+	ioasid_t pasid;
+
+	lockdep_assert_held(&iommu_sva_lock);
 
 	if (!arch_pgtable_dma_compat(mm))
-		return -EBUSY;
+		return ERR_PTR(-EBUSY);
 
-	mutex_lock(&iommu_sva_lock);
+	iommu_mm = mm->iommu_mm;
 	/* Is a PASID already associated with this mm? */
-	if (mm_valid_pasid(mm)) {
-		if (mm_get_pasid(mm) >= dev->iommu->max_pasids)
-			ret = -EOVERFLOW;
-		goto out;
+	if (iommu_mm) {
+		if (iommu_mm->pasid >= dev->iommu->max_pasids)
+			return ERR_PTR(-EOVERFLOW);
+		return iommu_mm;
 	}
 
 	iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
-	if (!iommu_mm) {
-		ret = -ENOMEM;
-		goto out;
-	}
+	if (!iommu_mm)
+		return ERR_PTR(-ENOMEM);
 
 	pasid = iommu_alloc_global_pasid(dev);
 	if (pasid == IOMMU_PASID_INVALID) {
 		kfree(iommu_mm);
-		ret = -ENOSPC;
-		goto out;
+		return ERR_PTR(-ENOSPC);
 	}
 	iommu_mm->pasid = pasid;
 	INIT_LIST_HEAD(&iommu_mm->sva_domains);
@@ -49,11 +48,7 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
 	 * valid iommu_mm with uninitialized values.
 	 */
 	smp_store_release(&mm->iommu_mm, iommu_mm);
-
-	ret = 0;
-out:
-	mutex_unlock(&iommu_sva_lock);
-	return ret;
+	return iommu_mm;
 }
 
 /**
@@ -74,23 +69,29 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
  */
 struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
 {
+	struct iommu_mm_data *iommu_mm;
 	struct iommu_domain *domain;
 	struct iommu_sva *handle;
 	int ret;
 
+	mutex_lock(&iommu_sva_lock);
+
 	/* Allocate mm->pasid if necessary. */
-	ret = iommu_sva_alloc_pasid(mm, dev);
-	if (ret)
-		return ERR_PTR(ret);
+	iommu_mm = iommu_alloc_mm_data(mm, dev);
+	if (IS_ERR(iommu_mm)) {
+		ret = PTR_ERR(iommu_mm);
+		goto out_unlock;
+	}
 
 	handle = kzalloc(sizeof(*handle), GFP_KERNEL);
-	if (!handle)
-		return ERR_PTR(-ENOMEM);
+	if (!handle) {
+		ret = -ENOMEM;
+		goto out_unlock;
+	}
 
-	mutex_lock(&iommu_sva_lock);
 	/* Search for an existing domain. */
 	list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
-		ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
+		ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
 		if (!ret) {
 			domain->users++;
 			goto out;
@@ -104,7 +105,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
 		goto out_unlock;
 	}
 
-	ret = iommu_attach_device_pasid(domain, dev, mm_get_pasid(mm));
+	ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
 	if (ret)
 		goto out_free_domain;
 	domain->users = 1;
@@ -119,10 +120,9 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
 
 out_free_domain:
 	iommu_domain_free(domain);
+	kfree(handle);
 out_unlock:
 	mutex_unlock(&iommu_sva_lock);
-	kfree(handle);
-
 	return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
@@ -220,9 +220,11 @@ iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
 
 void mm_pasid_drop(struct mm_struct *mm)
 {
-	if (likely(!mm_valid_pasid(mm)))
+	struct iommu_mm_data *iommu_mm = mm->iommu_mm;
+
+	if (!iommu_mm)
 		return;
 
-	iommu_free_global_pasid(mm_get_pasid(mm));
-	kfree(mm->iommu_mm);
+	iommu_free_global_pasid(iommu_mm->pasid);
+	kfree(iommu_mm);
 }
  

Hi Nicolin,

On 10/6/23 16:07, Nicolin Chen wrote:
> Hi Tina,
> 
> On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:
> 
>> Each mm bound to devices gets a PASID and corresponding sva domains
>> allocated in iommu_sva_bind_device(), which are referenced by iommu_mm
>> field of the mm. The PASID is released in __mmdrop(), while a sva domain
>> is released when no one is using it (the reference count is decremented
>> in iommu_sva_unbind_device()). However, although sva domains and their
>> PASID are separate objects such that their own life cycles could be
>> handled independently, an enqcmd use case may require releasing the
>> PASID in releasing the mm (i.e., once a PASID is allocated for a mm, it
>> will be permanently used by the mm and won't be released until the end
>> of mm) and only allows to drop the PASID after the sva domains are
>> released. To this end, mmgrab() is called in iommu_sva_domain_alloc() to
>> increment the mm reference count and mmdrop() is invoked in
>> iommu_domain_free() to decrement the mm reference count.
>>
>> Since the required info of PASID and sva domains is kept in struct
>> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old pasid
>> field in mm struct. The sva domain list is protected by iommu_sva_lock.
>>
>> Besides, this patch removes mm_pasid_init(), as with the introduced
>> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
>>
>> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
>> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> 
>> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
>>          struct device *dev = handle->dev;
>>
>>          mutex_lock(&iommu_sva_lock);
>> +       iommu_detach_device_pasid(domain, dev, pasid);
>>          if (--domain->users == 0) {
>> -               iommu_detach_device_pasid(domain, dev, pasid);
>> +               list_del(&domain->next);
>>                  iommu_domain_free(domain);
>>          }
>>          mutex_unlock(&iommu_sva_lock);
>> @@ -209,4 +224,5 @@ void mm_pasid_drop(struct mm_struct *mm)
>>                  return;
>>
>>          iommu_free_global_pasid(mm_get_pasid(mm));
>> +       kfree(mm->iommu_mm);
> 
> I ran some SVA tests by applying this series on top of my local
> SMMUv3 tree, though it is not exactly a vanilla mainline tree.
> And I see a WARN_ON introduced by this patch (did git-bisect):
> 
> [  364.237319] ------------[ cut here ]------------
> [  364.237328] ida_free called for id=12 which is not allocated.
> [  364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525 ida_free+0x10c/0x1d0
> ....
> [  364.237415] pc : ida_free+0x10c/0x1d0
> [  364.237416] lr : ida_free+0x10c/0x1d0
> ....
> [  364.237439] Call trace:
> [  364.237440]  ida_free+0x10c/0x1d0
> [  364.237442]  iommu_free_global_pasid+0x30/0x50
> [  364.237449]  mm_pasid_drop+0x44/0x70
> [  364.237452]  __mmdrop+0xf4/0x210
> [  364.237457]  finish_task_switch.isra.0+0x238/0x2e8
> [  364.237460]  schedule_tail+0x1c/0x1b8
> [  364.237462]  ret_from_fork+0x4/0x20
> [  364.237466] irq event stamp: 0
> [  364.237467] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
> [  364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
> [  364.237473] softirqs last  enabled at (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78
> [  364.237475] softirqs last disabled at (0): [<0000000000000000>] 0x0
> [  364.237476] ---[ end trace 0000000000000000 ]---
> 
> I haven't traced it closely to see what's wrong, due to some other
> tasks. Yet, if you have some idea about this or something that you
> want me to try, let me know.
Thanks for reporting this issue. I did some sva tests, but didn't run 
into this issue. I'm going to try more cases and let you know if I can 
find anything interesting.


Regards,
-Tina

> 
> Thanks
> Nicolin
  

Hi Jason,

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Saturday, October 7, 2023 2:06 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: Tian, Kevin <kevin.tian@intel.com>; Lu Baolu <baolu.lu@linux.intel.com>;
> Michael Shavit <mshavit@google.com>; Vasant Hegde
> <vasant.hegde@amd.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
> 
> On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> > Each mm bound to devices gets a PASID and corresponding sva domains
> > allocated in iommu_sva_bind_device(), which are referenced by
> iommu_mm
> > field of the mm. The PASID is released in __mmdrop(), while a sva
> > domain is released when no one is using it (the reference count is
> > decremented in iommu_sva_unbind_device()). However, although sva
> > domains and their PASID are separate objects such that their own life
> > cycles could be handled independently, an enqcmd use case may require
> > releasing the PASID in releasing the mm (i.e., once a PASID is
> > allocated for a mm, it will be permanently used by the mm and won't be
> > released until the end of mm) and only allows to drop the PASID after
> > the sva domains are released. To this end, mmgrab() is called in
> > iommu_sva_domain_alloc() to increment the mm reference count and
> > mmdrop() is invoked in
> > iommu_domain_free() to decrement the mm reference count.
> >
> > Since the required info of PASID and sva domains is kept in struct
> > iommu_mm_data of a mm, use mm->iommu_mm field instead of the old
> pasid
> > field in mm struct. The sva domain list is protected by iommu_sva_lock.
> >
> > Besides, this patch removes mm_pasid_init(), as with the introduced
> > iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> >
> > Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> > Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> > Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> > ---
> >
> > Change in v5:
> > - Use smp_store_release() & READ_ONCE() in storing and loading mm's
> >   pasid value.
> >
> > Change in v4:
> > - Rebase to v6.6-rc1.
> >
> >  drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++-----------
> -
> >  include/linux/iommu.h     | 18 +++++++++++-------
> >  kernel/fork.c             |  1 -
> >  3 files changed, 39 insertions(+), 20 deletions(-)
> 
> I was wondering what Nicolin's issue was, didn't see anything.
> 
> But I think you should incorporate this into the patch.
> 
> And there is a straightforward way to move the global lock into the
> iommu_mm_data that we can explore later.
OK. Let's try it. Hope this could solve the issue reported by Nicolin.

Regards,
-Tina
  

Hi Nicolin,

The v6 version has submitted: https://lore.kernel.org/linux-iommu/20231011065132.102676-1-tina.zhang@intel.com/

In v6 version, we make the iommu_sva_lock holding as a precondition for iommu_alloc_mm_data(). Although I think the issue you met probably wasn't caused by the iommu_sva_lock holding logic in iommu_sva_bind_device() of v5 patch-set. I guess it's worth a try.

Regards,
-Tina

> -----Original Message-----
> From: Zhang, Tina
> Sent: Tuesday, October 10, 2023 7:22 PM
> To: Nicolin Chen <nicolinc@nvidia.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin <kevin.tian@intel.com>; Lu
> Baolu <baolu.lu@linux.intel.com>; Michael Shavit <mshavit@google.com>;
> Vasant Hegde <vasant.hegde@amd.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
> 
> Hi Nicolin,
> 
> On 10/6/23 16:07, Nicolin Chen wrote:
> > Hi Tina,
> >
> > On Sun, Sep 24, 2023 at 07:38:12PM -0700, Tina Zhang wrote:
> >
> >> Each mm bound to devices gets a PASID and corresponding sva domains
> >> allocated in iommu_sva_bind_device(), which are referenced by
> >> iommu_mm field of the mm. The PASID is released in __mmdrop(), while
> >> a sva domain is released when no one is using it (the reference count
> >> is decremented in iommu_sva_unbind_device()). However, although sva
> >> domains and their PASID are separate objects such that their own life
> >> cycles could be handled independently, an enqcmd use case may require
> >> releasing the PASID in releasing the mm (i.e., once a PASID is
> >> allocated for a mm, it will be permanently used by the mm and won't
> >> be released until the end of mm) and only allows to drop the PASID
> >> after the sva domains are released. To this end, mmgrab() is called
> >> in iommu_sva_domain_alloc() to increment the mm reference count and
> >> mmdrop() is invoked in
> >> iommu_domain_free() to decrement the mm reference count.
> >>
> >> Since the required info of PASID and sva domains is kept in struct
> >> iommu_mm_data of a mm, use mm->iommu_mm field instead of the old
> >> pasid field in mm struct. The sva domain list is protected by
> iommu_sva_lock.
> >>
> >> Besides, this patch removes mm_pasid_init(), as with the introduced
> >> iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> >>
> >> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> >> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> >> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> >
> >> @@ -128,8 +142,9 @@ void iommu_sva_unbind_device(struct iommu_sva
> *handle)
> >>          struct device *dev = handle->dev;
> >>
> >>          mutex_lock(&iommu_sva_lock);
> >> +       iommu_detach_device_pasid(domain, dev, pasid);
> >>          if (--domain->users == 0) {
> >> -               iommu_detach_device_pasid(domain, dev, pasid);
> >> +               list_del(&domain->next);
> >>                  iommu_domain_free(domain);
> >>          }
> >>          mutex_unlock(&iommu_sva_lock); @@ -209,4 +224,5 @@ void
> >> mm_pasid_drop(struct mm_struct *mm)
> >>                  return;
> >>
> >>          iommu_free_global_pasid(mm_get_pasid(mm));
> >> +       kfree(mm->iommu_mm);
> >
> > I ran some SVA tests by applying this series on top of my local
> > SMMUv3 tree, though it is not exactly a vanilla mainline tree.
> > And I see a WARN_ON introduced by this patch (did git-bisect):
> >
> > [  364.237319] ------------[ cut here ]------------ [  364.237328]
> > ida_free called for id=12 which is not allocated.
> > [  364.237346] WARNING: CPU: 2 PID: 11003 at lib/idr.c:525
> > ida_free+0x10c/0x1d0 ....
> > [  364.237415] pc : ida_free+0x10c/0x1d0 [  364.237416] lr :
> > ida_free+0x10c/0x1d0 ....
> > [  364.237439] Call trace:
> > [  364.237440]  ida_free+0x10c/0x1d0
> > [  364.237442]  iommu_free_global_pasid+0x30/0x50 [  364.237449]
> > mm_pasid_drop+0x44/0x70 [  364.237452]  __mmdrop+0xf4/0x210 [
> > 364.237457]  finish_task_switch.isra.0+0x238/0x2e8
> > [  364.237460]  schedule_tail+0x1c/0x1b8 [  364.237462]
> > ret_from_fork+0x4/0x20 [  364.237466] irq event stamp: 0 [
> > 364.237467] hardirqs last  enabled at (0): [<0000000000000000>] 0x0 [
> > 364.237470] hardirqs last disabled at (0): [<ffffc0c16022e558>]
> > copy_process+0x770/0x1c78 [  364.237473] softirqs last  enabled at
> > (0): [<ffffc0c16022e558>] copy_process+0x770/0x1c78 [  364.237475]
> > softirqs last disabled at (0): [<0000000000000000>] 0x0 [  364.237476]
> > ---[ end trace 0000000000000000 ]---
> >
> > I haven't traced it closely to see what's wrong, due to some other
> > tasks. Yet, if you have some idea about this or something that you
> > want me to try, let me know.
> Thanks for reporting this issue. I did some sva tests, but didn't run into this
> issue. I'm going to try more cases and let you know if I can find anything
> interesting.
> 
> 
> Regards,
> -Tina
> 
> >
> > Thanks
> > Nicolin