Re: [PATCH v4] mm/userfaultfd: detect VMA replacement after copy retry in mfill_copy_folio_retry()

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 01, 2026 at 09:06:36AM +0100, David CARLIER wrote:
>   The invariant I was going for: "the folio we allocated is still
>   compatible with the VMA we're about to install it into." Since
>   alloc_folio() allocates from the VMA's backing file (inode), checking
>   that vm_file is still the same after re-acquiring locks ensures the
>   folio matches the inode. The vm_flags comparison was a secondary guard
>   against permission/type changes during the window.
> 
>   That said, I can see the vma_snapshot abstraction is doing too much for
>   what's really needed. Would a simpler approach work better — just
>   saving vm_file (with get_file/fput) before the drop and comparing it
>   directly after re-acquiring? That makes the invariant explicit: "same
>   backing file means the folio is valid for this VMA."

IMHO the flags is needed, consider a shared shmem vma remapped to a private
shmem vma.  That needs to be covered in the fix.

Actually instead of reducing checks, maybe we also need to check the offset
of the mapping too, that is: vma->vm_pgoff can't change otherwise it may
also affect how the back store would behave on this UFFDIO_COPY request.

For that, see the example of shmem_get_pgoff_policy() where it seems we can
apply different policies to different ranges of the back store.

Thanks,

-- 
Peter Xu