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

[Jose A. Perez de Azpillaga]

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 check the non-hugetlb retry already gets from
mfill_get_vma(). Patch 2 adds a uffd-unit-tests case for it, which fails
on hugetlb without patch 1.

Question:

- The non-hugetlb retry compares the whole mfill_retry_state. hugetlb
  copies into a freshly allocated folio, so only WP seemed to matter
  there. Mike, would you rather have the full comparison on both paths?

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

Based on mm-unstable.

Tested on x86_64 in QEMU.

[1] https://lore.kernel.org/20261015-urgent_fixes-v1-0-42796911043b@xxxxxxxxxx
[2] https://lore.kernel.org/20261015-urgent_fixes-v1-6-42796911043b@xxxxxxxxxx
[3] https://lore.kernel.org/20261027-fixes_core-v1-23-6f74bec9a5bb@xxxxxxxxxx (v1, now 23/47 in v2)

Jose A. Perez de Azpillaga (2):
  mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY
    retry
  selftests/mm: add a uffd test for re-registering during UFFDIO_COPY

 mm/userfaultfd.c                             |   4 +
 tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
 2 files changed, 109 insertions(+)


base-commit: 24d45a1475dd4c671feb1df705f67ef2fc293969
-- 
2.55.0