Re: [PATCH v4] mm/userfaultfd: detect VMA replacement after copy retry in mfill_copy_folio_retry()
From: David CARLIER
Date: Wed Apr 01 2026 - 14:41:58 EST
Hi Peter,
On Tue, Apr 01, 2026 at 04:23:00PM +0300, Peter Xu wrote:
> IMHO the flags is needed, consider a shared shmem vma remapped to a private
> shmem vma. That needs to be covered in the fix.
Right, I hadn't considered that case. Shared->private changes how
the
folio gets handled even with the same backing file. I'll keep the
flags
check.
> 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.
Good point. If vm_pgoff changes, linear_page_index() derives a
different page cache offset for the same virtual address, and
shmem_get_pgoff_policy() could apply a different NUMA policy to that
range. So the folio could end up at the wrong offset or with the wrong
placement.
I'll add vm_pgoff to the snapshot. So the full set of checks after
re-acquiring locks would be: vm_file, vm_flags, and vm_pgoff — ensuring
the folio was allocated for the right backing file, at the right
offset,
with the right VMA type.
Thanks