Re: [PATCH v5] mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()

Mike Rapoport
2026-04-09T18:12:38Z

On Thu, Apr 09, 2026 at 01:09:41PM -0400, Peter Xu wrote:
> On Thu, Apr 09, 2026 at 01:06:53PM +0100, David Carlier wrote:
> > @@ -465,6 +467,14 @@ static int mfill_copy_folio_retry(struct mfill_state *state, struct folio *folio
> > if (err)
> > return err;
> >
> > + /*
> > + * The VMA type may have changed while the lock was dropped
> > + * (e.g. replaced with a hugetlb mapping), making the caller's
> > + * ops pointer stale.
> > + */
> > + if (vma_uffd_ops(state->vma) != ops)
> > + return -EAGAIN;
>
> I agree with -EAGAIN here, but we discussed over all the things on possible
> inode change and I don't know why we don't consider that.
>
> I still think those should be considered.
>
> If the vma snapshot idea is not welcomed, fine. We need to think of
> something to cover those too. Current patch won't cover "ops unchaged" but
> "inode changed", or offset changed, for example.

This patch is enough to fix the regression introduced by my refactoring.

The inode/file/vma_snapshot checks are needed to solve the issue that
existed roughly for a decade.

This should be a separate patch and it's really not urgent.

> Thanks,
> --
> Peter Xu
>

--
Sincerely yours,
Mike.