> On Mar 11, 2026, at 10:59 AM, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> !-------------------------------------------------------------------|
>  This Message Is From an External Sender
>  This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
>> The -EINVAL originates from:
>> 
>> vfio_dma_do_map -> vfio_pin_map_dma -> vfio_pin_pages_remote
>> -> vaddr_get_pfns -> pin_user_pages_remote (mm/gup.c)
>> 
>> Possibly that’s also the origin of the concurrent PUD modification that requires
>> the retry in the walker in this patch.
> 
> We'd have to find out why we manage to trigger a -EINVAL here. I don't
> see how anything that this patch does could trigger that. So maybe a
> problem in user space? (calling it on unsupported VMAs?).
> 

It looks like I was mistaken the EINVAL being from pin_user_pages_remote, 
rather it originates from:

vfio_dma_do_map
  -> vfio_pin_map_dma
    -> vfio_pin_pages_remote
      -> vaddr_get_pfns
        -> follow_fault_pfn
          -> follow_pfnmap_start (mm/memory.c)

In vfio_iommu_type1.c, follow_fault_pfn first checks whether follow_pfnmap_start
returns an error; if it does, it calls fixup_user_fault to fault the mapping in and then 
retries follow_pfnmap_start to obtain the PFN.

Sounds to me that the walker is likely re-splitting the PUD entry between 
the fixup_user_fault and follow_pfnmap_start calls?