Addressing Sashiko AI review

From: Kiryl Shutsemau

Date: Mon Jul 06 2026 - 07:09:02 EST


Hi,

I went through the Sashiko review of v9. Only one (test-only) patch
needed changes; sent as v9.1 of 14/15 in this thread:

https://lore.kernel.org/all/20260706104906.36084-1-kirill@xxxxxxxxxxxxx/

- Tolerate EINVAL from madvise(MADV_NOHUGEPAGE) so the suite does not
abort on CONFIG_TRANSPARENT_HUGEPAGE=n.
- rwp-mprotect and rwp-fork-pin now assert the marker survived
(PM_UFFD_WP) before the access that auto-resolves it, so a kernel
that dropped the marker fails instead of passing vacuously.

The finding against 11/15 is a pre-existing PAGEMAP_SCAN inconsistency,
unrelated to RWP: an unpopulated pte is reported written by the
PAGE_IS_WRITTEN fast path but not by the generic path. Confirmed
reproducible; fixed separately with Fixes:/stable:

https://lore.kernel.org/all/20260706104308.34741-1-kirill@xxxxxxxxxxxxx/

The rest I assessed as false positives:

- 07/15, move_pages_huge_pmd() corrupting a non-present PMD: a
non-present source bails (-EAGAIN/-ENOENT) before the RWP re-arm,
and the post-lock pmd_same() recheck rejects races -- the re-arm
only runs on a present PMD.
- 07/15, UFFDIO_MOVE re-arming RWP "destroys resolved state": this is
intended. A MOVE-installed page starts tracked; the next guest
access is the working-set event we want (async auto-resolves it).
- 10/15, hugetlb stale-marker livelock after UFFDIO_UNREGISTER:
markers are cleared on unregister and on release via
change_protection(MM_CP_UFFD_RWP_RESOLVE); the rwp-close tests
exercise this on hugetlb.
- 13/15, check_stable_address_space() before the VMA walk in
UFFDIO_SET_MODE: the ioctl holds mmget_not_zero() + mmap_write_lock
and only takes per-VMA locks, and a ctx on a failed-fork mm is
never published to userspace.

The 09/15 findings (userfaultfd_clear_vma() touching ptes before
vma_start_write(), the partial-unregister OOM rollback, and UFFDIO_MOVE
dropping uffd-wp markers) are pre-existing and left as-is; pte-level
access there is serialised by the pte lock.

Ping me if any of these assessments seems off.

--
Kiryl Shutsemau / Kirill A. Shutemov