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

[Peter Xu]

On Sun, Apr 12, 2026 at 06:46:17PM +0300, Mike Rapoport wrote:
> > 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?

It was confusing indeed that I used as example, sorry. SOFTDIRTY only case
isn't a bug, even if it'll also be captured by "vma changes" when we detect
that.

I just wanted to say I concerned much less on arbitrary hugetlbfs vmas
appearing than most of the rest, where it can crash the kernel even after
the change (e.g. mapped one shmem inode, remapped to another different
shmem inode, or SHARED->PRIVATE, as others pointed out elsewhere).

> 
> > 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