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/[email protected]/ - 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/[email protected]/ 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
