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

[Mike Rapoport]

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.