Re: [PATCH RESEND] userfaultfd: snapshot VMA state across UFFDIO_COPY retry

[Lorenzo Stoakes]

On Tue, May 26, 2026 at 02:47:45PM +0200, David Hildenbrand (Arm) wrote:
> On 5/25/26 19:12, Liam R. Howlett wrote:
> > On 26/05/20 04:38PM, David Hildenbrand (Arm) wrote:
> >> On 5/20/26 16:12, Mike Rapoport wrote:
> >>>
> >>> Let me reiterate:
> >>>
> >>> A thread doing UFFDIO_COPY releases the VMA in mfill_copy_folio_retry(),
> >>> re-gets the VMA and checks if the per-MM counter stayed the same.
> >>>
> >>> If another thread makes any change to VMA while mfill_copy_folio_retry()
> >>> waits to re-get the VMA, the counter would be incremented by another
> >>> thread. mfill_copy_folio_retry() will see the change after mfill_get_vma()
> >>> and will bail out with -EAGAIN.
> >>>
> >>
> >> Yeah.
> >
> > This isn't bulletproof anyways.  The sequence count can wrap.  So, if
> > someone can replace the vma then cause the sequence counter wrap, then
> > you can be fooled into thinking it's okay (we had this problem years ago
> > with the vmacache using a 32 bit counter, iirc).
>
> If you can get it to wrap for such short durations, then how would sequence
> counters possibly work in any reasonable context?

Surely even for a 32-bit value, we can be pretty confident we're not going to
see a wrap that matters (the seqnum will != the prev seqnum unless 4 billion VMA
write locks were obtained)?

I may be missing something though!

>
> --
> Cheers,
>
> David

Thanks, Lorenzo