On Wed, Jul 08, 2026 at 08:08:44PM -0700, Andrew Morton wrote: > On Wed, 8 Jul 2026 11:34:29 +0100 Kiryl Shutsemau <[email protected]> > wrote: > > > From: "Kiryl Shutsemau (Meta)" <[email protected]> > > > > PAGEMAP_SCAN reports an unpopulated PTE in a uffd-wp VMA as written > > (pagemap_page_category() and the PAGE_IS_WRITTEN fast path), but a range > > with no page table at all -- a PMD hole -- is skipped. > > pagemap_scan_pte_hole() evaluates the hole against p->cur_vma_category, > > which pagemap_scan_test_walk() builds from only PAGE_IS_WPALLOWED and > > PAGE_IS_SOFT_DIRTY, so PAGE_IS_WRITTEN is never set: the hole is neither > > reported nor, under PM_SCAN_WP_MATCHING, armed. > > > > This is reachable. An anonymous THP is write-protected in place as a huge > > PMD (change_huge_pmd(), anon is not split), and a full-PMD MADV_DONTNEED > > clears it to pmd_none. A WP-async consumer such as CRIU then misses the > > 2MB drop -- the range is not reported written and the next incremental > > dump keeps stale data. (A file/shmem THP is split on write-protect, so a > > later DONTNEED leaves a populated page table of pte_none entries, which > > are already reported; only anon THP reaches the hole path.) > > > > Add PAGE_IS_WRITTEN to the categories evaluated for a hole in a > > non-hugetlb uffd-wp VMA, matching the pte_none handling in > > pagemap_page_category(). The existing PM_SCAN_WP_MATCHING path then also > > arms the range: uffd_wp_range() allocates the page table and installs > > markers under WP_UNPOPULATED, so the next scan sees it clean until > > re-written. > > > > hugetlb is excluded on purpose: an allocated-but-empty huge entry reads > > as not-written via pagemap_hugetlb_category(), so reporting an > > unallocated hugetlb hole (which also reaches this path) as written would > > be inconsistent within the same VMA. hugetlb hole handling is left as-is. > > > > Add a pagemap_ioctl selftest that forms an anon THP, drops it with > > MADV_DONTNEED and checks the resulting PMD hole is reported written. > > hoo boy, that was heavy going.
Will make it brief in v3. > > Assisted-by: Claude:claude-fable-5 > > OK ;) > > But what do our users see? afaict the result of the bug is "the next > incremental CRIU dump keeps stale data". Why is this a problem? How > would operators look at a user bug report and figure out that this > patch will address it? The core point is that MADV_DONTNEED has fill-with-zeros semantics and should be treated as write for write-tracking purposes. Ideally, we want to have PMD marker here, but we don't have enough infra to handle non-present PMD entries. Usama works on this. > Is there some Reported-by/Closes? Closes: https://sashiko.dev/#/patchset/[email protected] -- Kiryl Shutsemau / Kirill A. Shutemov
