Addressing Sashiko AI review

[Kiryl Shutsemau <kas@kernel.org>]

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@shutemov.name/

  - 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@shutemov.name/

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