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

[Mike Rapoport]

On Thu, Apr 02, 2026 at 09:29:56AM -0400, Peter Xu wrote:
> 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?

I don't think that "munmap + mmap + userfault_register"
during an outstanding UFFDIO_COPY to the same range is, hmm, the smartest
thing to do, and I think aborting the outstanding UFFDIO_COPY in such case
is better than allowing it to continue.
 
> 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.

Right, we shouldn't fail if some of the VMA flags changed, but we are
talking about of complete change of the mapping, with potentially
completely different backing store.
 
> Thanks,
> -- 
> Peter Xu

-- 
Sincerely yours,
Mike.