[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251029133434.GL760669@ziepe.ca>
Date: Wed, 29 Oct 2025 10:34:34 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Shuai Xue <xueshuai@...ux.alibaba.com>
Cc: iommu@...ts.linux.dev, kevin.tian@...el.com, joro@...tes.org,
	will@...nel.org, robin.murphy@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu: iommufd: Explicitly check for VM_PFNMAP in
 iommufd_ioas_map
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
Powered by blists - more mailing lists
 
