Linux IOMMU Development
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: Baolu Lu <baolu.lu@linux.intel.com>, <joro@8bytes.org>,
	<jgg@nvidia.com>, <kevin.tian@intel.com>
Cc: <eric.auger@redhat.com>, <nicolinc@nvidia.com>,
	<chao.p.peng@linux.intel.com>, <iommu@lists.linux.dev>,
	<vasant.hegde@amd.com>, <will@kernel.org>
Subject: Re: [PATCH v6 03/14] iommufd: Move the iommufd_handle helpers to device.c
Date: Fri, 20 Dec 2024 14:34:42 +0800	[thread overview]
Message-ID: <f19ea3cd-2f31-45c9-a1d5-5e5b754a191a@intel.com> (raw)
In-Reply-To: <a2f363e7-88e4-46ef-8755-8a5e0cc47ecc@linux.intel.com>

On 2024/12/20 11:31, Baolu Lu wrote:
> On 12/19/24 21:27, Yi Liu wrote:
>> The iommu_attach_handle is now only passed when attaching iopf-capable
>> domain, while it is not convenient for the iommu core to track the
>> attached domain of pasids. To address it, the iommu_attach_handle will
>> be passed to iommu core for non-fault-able domain as well. Hence the
>> iommufd_handle related helpers are no longer fault specific, it makes
>> more sense to move it out of fault.c.
>>
>> Signed-off-by: Yi Liu<yi.l.liu@intel.com>
>> ---
>>   drivers/iommu/iommufd/device.c          | 62 +++++++++++++++++++++++++
>>   drivers/iommu/iommufd/fault.c           | 56 +---------------------
>>   drivers/iommu/iommufd/iommufd_private.h |  8 ++++
>>   3 files changed, 72 insertions(+), 54 deletions(-)
>>
>> diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
>> index dfd0898fb6c1..0e1baf84e887 100644
>> --- a/drivers/iommu/iommufd/device.c
>> +++ b/drivers/iommu/iommufd/device.c
>> @@ -293,6 +293,68 @@ u32 iommufd_device_to_id(struct iommufd_device *idev)
>>   }
>>   EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, "IOMMUFD");
>> +/**
>> + * iommufd_device_get_attach_handle - Return the attach handle for the RID
>> + *
>> + * @idev: The device to get attach_handle
>> + *
>> + * Currently there is no locking to synchronize threads that access the
>> + * returned handle with those attaching or replacing the domain which might
>> + * change the handle. It's caller's duty to guarantee no use-after-free.
> 
> It's better to make "It's caller's duty to guarantee no use-after-free"
> more specific. Something like, the caller is responsible for ensuring
> that the returned pointer is not used after the domain is removed from
> the device's RID.

ok.

>> + *
>> + * Return valid attach_handle if there is, otherwise NULL.
>> + */
>> +struct iommufd_attach_handle *
>> +iommufd_device_get_attach_handle(struct iommufd_device *idev)
>> +{
>> +    struct iommu_attach_handle *handle;
>> +
>> +    handle = iommu_attach_handle_get(idev->igroup->group, 
>> IOMMU_NO_PASID, 0);
>> +    if (IS_ERR(handle))
>> +        return NULL;
>> +
>> +    return to_iommufd_handle(handle);
>> +}
>> +
>> +int iommufd_dev_attach_handle(struct iommufd_hw_pagetable *hwpt,
>> +                  struct iommufd_device *idev)
>> +{
>> +    struct iommufd_attach_handle *handle;
>> +    int ret;
>> +
>> +    handle = kzalloc(sizeof(*handle), GFP_KERNEL);
>> +    if (!handle)
>> +        return -ENOMEM;
>> +
>> +    handle->idev = idev;
>> +    ret = iommu_attach_group_handle(hwpt->domain, idev->igroup->group,
>> +                    &handle->handle);
>> +    if (ret)
>> +        kfree(handle);
>> +
>> +    return ret;
>> +}
>> +
>> +int iommufd_dev_replace_handle(struct iommufd_device *idev,
>> +                   struct iommufd_hw_pagetable *hwpt,
>> +                   struct iommufd_hw_pagetable *old)
>> +{
>> +    struct iommufd_attach_handle *handle;
>> +    int ret;
>> +
>> +    handle = kzalloc(sizeof(*handle), GFP_KERNEL);
>> +    if (!handle)
>> +        return -ENOMEM;
>> +
>> +    handle->idev = idev;
>> +    ret = iommu_replace_group_handle(idev->igroup->group,
>> +                     hwpt->domain, &handle->handle);
>> +    if (ret)
>> +        kfree(handle);
>> +
>> +    return ret;
>> +}
> 
> Where will the old handle be freed? It seems unreasonable to allocate
> the handle in these helper functions, only to have it freed by callers
> in other files.

yes, it's in the caller side. See the below snippet in patch 02. Maybe
it's an over work to split this patch with patch 04. Merging them may
be helpful. Nic has a proposed patch as well for such purpose.

@@ -196,13 +187,24 @@ int iommufd_fault_domain_replace_dev(struct 
iommufd_device *idev,
  			return ret;
  	}

-	ret = __fault_domain_replace_dev(idev, hwpt, old);
+	curr = iommufd_device_get_attach_handle(idev);
+
+	if (hwpt->fault)
+		ret = __fault_domain_replace_dev(idev, hwpt, old);
+	else
+		ret = iommu_replace_group_handle(idev->igroup->group,
+						 hwpt->domain, NULL);
  	if (ret) {
  		if (iopf_on)
  			iommufd_fault_iopf_disable(idev);
  		return ret;
  	}

+	if (curr) {
+		iommufd_auto_response_faults(old, curr);
+		kfree(curr);
+	}
+


-- 
Regards,
Yi Liu

  reply	other threads:[~2024-12-20  6:30 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 13:27 [PATCH v6 00/14] iommufd support pasid attach/replace Yi Liu
2024-12-19 13:27 ` [PATCH v6 01/14] iommu: Introduce a replace API for device pasid Yi Liu
2024-12-20  2:47   ` Baolu Lu
2025-01-09  7:08   ` Tian, Kevin
2025-01-09  7:20   ` Tian, Kevin
2025-01-09 14:43     ` Jason Gunthorpe
2025-01-10  2:31       ` Baolu Lu
2025-01-10  7:21         ` Tian, Kevin
2025-01-16 10:00           ` Yi Liu
2025-01-13 20:21   ` Jason Gunthorpe
2025-01-14  8:10     ` Tian, Kevin
2025-01-14 13:45       ` Jason Gunthorpe
2025-01-15  4:43         ` Tian, Kevin
2025-01-15 14:43           ` Jason Gunthorpe
2025-01-16  5:48             ` Tian, Kevin
2025-01-17 10:32               ` Yi Liu
2024-12-19 13:27 ` [PATCH v6 02/14] iommufd: Refactor __fault_domain_replace_dev() to be a wrapper of iommu_replace_group_handle() Yi Liu
2024-12-19 13:27 ` [PATCH v6 03/14] iommufd: Move the iommufd_handle helpers to device.c Yi Liu
2024-12-20  3:31   ` Baolu Lu
2024-12-20  6:34     ` Yi Liu [this message]
2024-12-19 13:27 ` [PATCH v6 04/14] iommufd: Always pass iommu_attach_handle to iommu core Yi Liu
2024-12-20  4:35   ` Nicolin Chen
2024-12-20  6:40     ` Yi Liu
2024-12-20  6:58       ` Nicolin Chen
2025-01-09  7:44   ` Tian, Kevin
2025-01-17 12:33     ` Yi Liu
2025-01-17 19:03       ` Nicolin Chen
2024-12-19 13:27 ` [PATCH v6 05/14] iommufd: Pass pasid through the device attach/replace path Yi Liu
2025-01-09  7:53   ` Tian, Kevin
2025-01-09 14:51     ` Jason Gunthorpe
2025-01-10  7:22       ` Tian, Kevin
2024-12-19 13:27 ` [PATCH v6 06/14] iommufd: Mark PASID-compatible domain Yi Liu
2025-01-09  7:56   ` Tian, Kevin
2025-01-09 14:54   ` Jason Gunthorpe
2025-01-17 10:50     ` Yi Liu
2024-12-19 13:27 ` [PATCH v6 07/14] iommufd: Support pasid attach/replace Yi Liu
2025-01-09  8:25   ` Tian, Kevin
2024-12-19 13:27 ` [PATCH v6 08/14] iommufd: Enforce PASID-compatible domain for RID Yi Liu
2025-01-09  8:31   ` Tian, Kevin
2024-12-19 13:27 ` [PATCH v6 09/14] iommu/vt-d: Add IOMMU_HWPT_ALLOC_PASID support Yi Liu
2024-12-23  2:51   ` Baolu Lu
2024-12-24 11:35     ` Yi Liu
2024-12-25  1:02       ` Baolu Lu
2024-12-25  4:30         ` Yi Liu
2024-12-25  7:13           ` Baolu Lu
2025-02-12  7:47             ` Yi Liu
2025-02-12 12:59               ` Jason Gunthorpe
2025-02-13  9:34                 ` Yi Liu
2025-02-13 12:56                   ` Jason Gunthorpe
2025-02-14  3:24                     ` Yi Liu
2025-02-12 13:00               ` Robin Murphy
2025-02-12 13:08                 ` Jason Gunthorpe
2025-02-13 10:10                 ` Yi Liu
2025-02-13 10:24                   ` Robin Murphy
2025-02-13 12:53                     ` Yi Liu
2025-02-19  8:02                     ` Tian, Kevin
2025-02-19 12:50                       ` Yi Liu
2025-02-20  6:57                         ` Tian, Kevin
2025-01-09 15:27     ` Jason Gunthorpe
2025-01-10  2:41       ` Baolu Lu
2025-01-10  7:34         ` Tian, Kevin
2025-01-17 10:57           ` Yi Liu
2025-01-10  7:38   ` Tian, Kevin
2025-01-14  8:13     ` Tian, Kevin
2025-01-13 20:31   ` Jason Gunthorpe
2025-01-14  8:19     ` Tian, Kevin
2024-12-19 13:27 ` [PATCH v6 10/14] iommufd: Allow allocating PASID-compatible domain Yi Liu
2024-12-19 13:27 ` [PATCH v6 11/14] iommufd/selftest: Add set_dev_pasid in mock iommu Yi Liu
2024-12-19 13:27 ` [PATCH v6 12/14] iommufd/selftest: Add a helper to get test device Yi Liu
2024-12-19 13:27 ` [PATCH v6 13/14] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2024-12-19 13:27 ` [PATCH v6 14/14] iommufd/selftest: Add coverage for iommufd " Yi Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f19ea3cd-2f31-45c9-a1d5-5e5b754a191a@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=nicolinc@nvidia.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox