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

[David CARLIER <devnexen@gmail.com>]

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