Re: [PATCH v2] fs/proc/task_mmu: fix PAGEMAP_SCAN written state for PMD holes

[Kiryl Shutsemau]

On Wed, Jul 08, 2026 at 08:08:44PM -0700, Andrew Morton wrote:
> On Wed,  8 Jul 2026 11:34:29 +0100 Kiryl Shutsemau <kirill@xxxxxxxxxxxxx> wrote:
> 
> > From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
> > 
> > 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/20260707151349.92143-1-kirill@xxxxxxxxxxxxx

-- 
  Kiryl Shutsemau / Kirill A. Shutemov