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

Peter Xu
2026-04-01T15:23:26Z

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