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

[David CARLIER]

On Tue, Apr 01, 2026 at 08:22:00PM +0300, Peter Xu wrote:
  > When caching the offset, we should likely use linear_page_index() with the
  > address provided rather than caching vma->vm_pgoff directly, then
it'll
  > avoid same vm_pgoff while VMA mapping shifted like this:
  >
  >   VMA1:  vm_pgoff=0x10000, vm_start=0x10000
  >   VMA2:  vm_pgoff=0x10000, vm_start=0xf000

  Makes sense. linear_page_index() folds in vm_start so it catches the
  shifted mapping case where raw vm_pgoff alone wouldn't. I'll snapshot
  the computed pgoff instead.

  > The other thing is I just noticed the err code was changed to -EINVAL for
  > snapshot changed cases, sorry I didn't follow previously as closely on the
  > discussion.  I think it should be -EAGAIN.  It's because the userapp can't
  > resolve -EINVAL failures and app will crash.  In a VMA change use
case, we
  > should return -EAGAIN to imply the app to retry, rather than crashing.

  Right, -EAGAIN is the correct choice here. The VMA changed underneath
  us, but that's a transient condition the app can recover from by
  retrying. Will fix.

  So v5 will snapshot: vm_file (with get_file/fput), vm_flags, and
  linear_page_index(vma, dst_addr). Return -EAGAIN if any changed.

  Thanks for the detailed review