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

David CARLIER
2026-04-01T20:05:48Z

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