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

Peter Xu
2026-04-02T13:30:06Z

Hi, Mike,

On Thu, Apr 02, 2026 at 07:02:40AM +0300, Mike Rapoport wrote:
> On Wed, Apr 01, 2026 at 03:22:03PM -0400, Peter Xu wrote:
> >
> > 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.
>
> No. The return value should express that the VMA is invalid. -EINVAL could
> work, but looking now at the manual -ENOENT would be even better:
>
> ENOENT (since Linux 4.11)
> The faulting process has changed its virtual memory layout
> simultaneously with an outstanding UFFDIO_COPY operation.

The VMA changed, but it doesn't mean the UFFDIO_COPY becomes illegal, am I
right?

For example, I wonder if it's possible someone runs soft-dirty concurrently
with userfaultfd, we shouldn't fail the userapp if there's a concurrent
thread collecting dirty information, which IIUC can cause VMA flag changes,
and should be benign, and I think there can be other things causing the
interruption too.

-EAGAIN essentially requested the user to retry. If the VMA is not legal
to be operated anymore, it will fail later. However we should allow legal
users to pass.

Thanks,

--
Peter Xu