Re: [PATCH v2 0/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Andrew Morton]

On Mon,  2 Nov 2026 09:11:29 +0100 "Jose A. Perez de Azpillaga" <azpijr@xxxxxxxxx> wrote:

> The urgent fixes made hugetlb_fault() tolerate uffd bits left in VMAs
> that are no longer registered for them, and asked for follow-ups that
> remove the sources [1]. This is one: a hugetlb UFFDIO_COPY_MODE_WP copy
> that has to fault in its source page doesn't recheck the WP registration
> before retrying, so re-registering the range without WP in that window
> leaves a uffd-wp PTE behind.
> 
> Patch 1 adds the missing check. Patch 2 adds a uffd-unit-tests case for
> it, which fails on hugetlb without patch 1.
> 
> The other source 6/10 of [1] mentions, UFFDIO_COPY in MODE_WP racing
> with UFFDIO_UNREGISTER [2], is closed by "mm/userfaultfd: write-lock the
> VMA before waking waiters when unregistering" [3].

Thanks.

Sashiko isn't entirely happy:
	https://sashiko.dev/#/patchset/20261102081140.201987-1-azpijr@xxxxxxxxx

Also, for those who believe uffd is now defect free:

: Separately, mwriteprotect_range() checks the WP flag but not which
: userfaultfd owns the VMA. With two userfaultfds in one mm, unprotecting
: B's range through A can clear B's WP but wake A's queues, leaving B's
: writer asleep. mrwprotect_range() has the same ownership-check omission.
: This is older and deserves a separate fix.