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

[Mike Rapoport]

On Fri, Apr 10, 2026 at 11:26:55AM -0400, Peter Xu wrote:
> On Thu, Apr 09, 2026 at 02:31:46PM +0300, Mike Rapoport wrote:
> > On Thu, Apr 02, 2026 at 09:42:01AM -0400, Peter Xu wrote:
> > 
> > My point was that this is preexisting bug and that we don't need to rush
> > with the complete fix that will extensively compare VMA compatibility...
> 
> Yes, I fully agree it was pre-existing.  My guess is we only didn't reach a
> consensus yet on how to completely fix it, and whether we need an
> intermediate fix for "a VMA suddenly changed to hugetlb" only.

Such intermediate fix will keep bug backwards compatibility :)

> > > > This is still a footgun, but I don't see it as a big deal.
> > > 
> > > IIUC this is a real bug reported.  Actually, if my understanding is
> > > correct, we should be able to easily write a reproducer by registering the
> > > src addr of UFFDIO_COPY to userfaultfd too, then the ioctl(UFFDIO_COPY)
> > > thread will get blocked faulting in the src_addr.  During that, we can
> > > change the VMA layout in another thread to test whatever setup we want.
> > > 
> > > > Let's revisit it after -rc1 and please make sure to cc "MEMORY MAPPING"
> > > > folks for insights about how to better track VMA changes or their absence.
> > > 
> > > No strong feeling here if we want to slightly postpone this fix.  It looks
> > > like not easy to happen as it looks to be a bug present for a while, indeed.
> > > 
> > > It's just that if my understanding is correct, with above reproducer we can
> > > crash the kernel easily without a proper fix.
> >  
> > ... but we do need a more urgent fix for the case when a VMA suddenly
> > becomes hugetlb, because that could not happen before the refactoring.
> 
> Personally this is least of a concern to me. Hugetlbfs is so specially
> managed in userapps, so it is even less likely to trigger the same bug with
> VM_SOFTDIRTY changes or other ways.
 
I'm not sure I follow you here. How changes of VM_SOFTDIRTY can crash the
kernel in UFFDIO_COPY?

> Again, I'm open to any suggestion on replacing the vma snapshot logic as
> long as all possible issues got reported will be properly fixed, especially
> in the latest mainline. I don't worry much on backporting yet; if this bug
> existed for 10 years and nobody yet reported, to me we can always evaluate
> the effort to backport or skip.  However, a proper fix in mainline is IMHO
> more important.

Totally agree, a fix in mainline is much more important than backporting.
 
> Thanks,
> -- 
> Peter Xu
> 

-- 
Sincerely yours,
Mike.