Re: [RFC 1/1] mm/pagewalk: don't split device-backed huge pfnmaps

[David Hildenbrand (Arm)]

On 3/11/26 12:14, Boone, Max wrote:
> 
> 
>> On Mar 11, 2026, at 11:45 AM, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
>>
>> The code in follow_fault_pfn() should likely be updated to handle more
>> than one attempt. That's also what GUP does.
>>
>> Likely, follow_fault_pfn() was never taught about PFNMAP mappings that
>> can be faulted+zapped (in the past they were always static).
>>
>> If you turn that into a (possibly) endless loop, does the problem go away?
> 
> Yep, was just trying that - with this change the problem goes away:
> 
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -532,7 +532,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma, struct mm_struct *mm,
> 
>                 ret = follow_pfnmap_start(&args);
>                 if (ret)
> -                       return ret;
> +                       return -EAGAIN;
>         }

Looks like follow_pfnmap_start() only ever returns -EINVAL: for invalid
parameters (unexpected) and non-present entries.

Returning -ENOENT when there is no actual entry would be clearer. Then
you could just translate -ENOENT to -EAGAIN.

But just always using -EAGAIN should be fine here I guess.

> 
>         if (write_fault && !args.writable)
> 
> —
> 
> I’ll propose that with the VFIO folks when I get the patch for mm/pagewalk.c ready and will refer
> to that patch, or would it be better to propose two commits under the same cover letter?

Probably be best to send two separate patches. One MM fix and one vfio
fix. :)

> 
> I can have a look at follow_fault_pfn but this problem is my first time diving into linux mm
> so that will probably take a while (and some reading up on my end).
No worries, just let me know if you have any questions.

-- 
Cheers,

David