From: Jason Gunthorpe <jgg@ziepe.ca>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: iommu@lists.linux.dev, kevin.tian@intel.com, joro@8bytes.org,
will@kernel.org, robin.murphy@arm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu: iommufd: Explicitly check for VM_PFNMAP in iommufd_ioas_map
Date: Wed, 29 Oct 2025 10:34:34 -0300 [thread overview]
Message-ID: <20251029133434.GL760669@ziepe.ca> (raw)
In-Reply-To: <20251029125226.81949-1-xueshuai@linux.alibaba.com>
On Wed, Oct 29, 2025 at 08:52:26PM +0800, Shuai Xue wrote:
> The iommufd_ioas_map function currently returns -EFAULT when attempting
> to map VM_PFNMAP VMAs because pin_user_pages_fast() cannot handle such
> mappings. This error code is misleading and does not accurately reflect
> the nature of the failure.
Sure, but why do you care? Userspace should know not to do this based
on how it created the mmaps, not rely on errnos to figure it out after
the fact.
> +static bool iommufd_check_vm_pfnmap(unsigned long vaddr)
> +{
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> + bool ret = false;
> +
> + mmap_read_lock(mm);
> + vaddr = untagged_addr_remote(mm, vaddr);
> + vma = vma_lookup(mm, vaddr);
> + if (vma && vma->vm_flags & VM_PFNMAP)
> + ret = true;
> + mmap_read_unlock(mm);
This isn't really sufficient, the range can span multiple VMAs and you
can hit special PTEs in PFNMAPs, or you can hit P2P struct pages in
fully normal VMAs.
I think if you really want this errno distinction it should come from
pin_user_pages() directly as only it knows the reason it didn't work.
Jason
next prev parent reply other threads:[~2025-10-29 13:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 12:52 [PATCH] iommu: iommufd: Explicitly check for VM_PFNMAP in iommufd_ioas_map Shuai Xue
2025-10-29 13:34 ` Jason Gunthorpe [this message]
2025-10-29 14:44 ` Shuai Xue
2025-10-29 14:49 ` Jason Gunthorpe
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=20251029133434.GL760669@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=xueshuai@linux.alibaba.com \
/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