From: Richard Gemego <richardgemego@gmail.com>
To: Nicolin Chen <nicolinc@nvidia.com>,
Pranjal Shrivastava <praan@google.com>
Cc: baolu.lu@linux.intel.com, kevin.tian@intel.com, jgg@ziepe.ca,
iommu@lists.linux.dev, Quan Zhou <zhouquan@iscas.ac.cn>
Subject: Re: [PATCH] iommufd: fix returns ENOENT in iommufd_viommu_get_vdev_id()
Date: Tue, 5 Aug 2025 10:46:20 +0800 [thread overview]
Message-ID: <c603856a-44ae-4ff9-8fe7-7cb48d78617e@gmail.com> (raw)
In-Reply-To: <aJDxfiP8n3YLye1Z@Asurada-Nvidia>
Hello, maintainers!
The motivation of this fix is when iommufd in selftests tested on RISC-V,
I found that `alloc_hwpt_nested` items are failed, then I followed the
function calling chains and found that in iommufd_viommu_get_vdev_id(),
there is always not any vdev in viommu. I wonder if it is because RISC-V
does not support vIOMMU well, so that there isn't any any vdev in
viommu, then iommufd_viommu_get_vdev_id() will always return
-ENOENT. Have you ever tested it on RISC-V? Will viommu always have
at least one vdev on ARM (since you have mentioned ARM in ea94b211c548
patch series), so iommufd_viommu_get_vdev_id() can return 0 in iommufd
selftest?
Thank you!
On 8/5/2025 1:44 AM, Nicolin Chen wrote:
> On Mon, Aug 04, 2025 at 11:25:42AM +0000, Pranjal Shrivastava wrote:
>> On Mon, Aug 04, 2025 at 06:08:59PM +0800, Richard Gemego wrote:
>>> In iommufd_viommu_get_vdev_id(), if viommu does not have any vdevs, fix
>>> this func to return 0 instead of ENOENT.
> I think this is missing some justification explaining why this is
> a fix.
>
>>> Fixes: ea94b211c548 ("iommufd/viommu: Add iommufd_viommu_get_vdev_id helper")
>>> Signed-off-by: Richard Gemego <richardgemego@gmail.com>
>>> Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
>>> ---
>>> drivers/iommu/iommufd/driver.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/iommu/iommufd/driver.c b/drivers/iommu/iommufd/driver.c
>>> index 922cd1fe7ec2..ad635af8555b 100644
>>> --- a/drivers/iommu/iommufd/driver.c
>>> +++ b/drivers/iommu/iommufd/driver.c
>>> @@ -68,6 +68,7 @@ int iommufd_viommu_get_vdev_id(struct iommufd_viommu *viommu,
>>> break;
>>> }
>>> }
>>> + if (!index)
>>> + rc = 0;
>>> xa_unlock(&viommu->vdevs);
>>> return rc;
>>> }
>> I'm afraid, I don't understand the motivation behind this? IIUC, if a
>> dev is not associated to the vIOMMU -ENOENT is returned. This patch
>> seems to be returning 0 when the xarray is empty. The issue is that
>> returning 0, would indicate the caller that `*vdev_id` holds a valid
>> value which doesn't seem to be the case here?
> The function is designed to return -ENOENT for an empty xarray:
>
> /* Return -ENOENT if device is not associated to the vIOMMU */
>
> And 0 would be a valid vdev ID in the xarray.
>
> Nicolin
next prev parent reply other threads:[~2025-08-05 2:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 10:08 [PATCH] iommufd: fix returns ENOENT in iommufd_viommu_get_vdev_id() Richard Gemego
2025-08-04 11:25 ` Pranjal Shrivastava
2025-08-04 17:44 ` Nicolin Chen
2025-08-05 2:46 ` Richard Gemego [this message]
2025-08-05 3:33 ` Nicolin Chen
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=c603856a-44ae-4ff9-8fe7-7cb48d78617e@gmail.com \
--to=richardgemego@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=zhouquan@iscas.ac.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.