Re: [PATCH v3] mm/ksm: keep soft-dirty when merging a page

[Andrew Morton]

On Wed, 21 Oct 2026 11:21:57 -0700 Samarth Narang <samarth.colleges@xxxxxxxxx> wrote:

> replace_page() maps the KSM page with a PTE built from scratch, so the
> soft-dirty bit of the PTE it replaces is lost. A page written since
> "clear_refs 4" then no longer shows as soft-dirty once it is merged, and
> a soft-dirty based dumper treats it as unchanged.
> 
> Copy the soft-dirty bit from the original PTE to the new PTE.

Thanks.  My LLM review thing says:

: There's a separate, pre-existing problem with the KSM zero-page
: path which is worth pointing out.
: 
: When use_zero_pages is enabled, replace_page() constructs the
: replacement PTE using:
: 
:     newpte = pte_mkdirty(pte_mkspecial(pfn_pte(...)));
: 
: The dirty bit is deliberately set so that KSM can distinguish its
: own zero-page mappings from ordinary zero-page mappings. However,
: on x86, pte_mkdirty() sets both _PAGE_DIRTY and _PAGE_SOFT_DIRTY.
: 
: Consequently, a process can clear its soft-dirty bits through
: /proc/PID/clear_refs, perform no further writes, and subsequently
: have a page marked soft-dirty simply because KSM merged an all-zero
: page. Userspace then sees bit 55 set in /proc/PID/pagemap even though
: the page hasn't been modified since tracking was reset.
: 
: Your patch doesn't introduce this problem, but it doesn't fix it
: either. The new pte_soft_dirty(orig_pte) check cannot help in the
: zero-page case because pte_mkdirty() has already set the bit in
: newpte.
: 
: I don't think this should hold up v3. Losing soft-dirty when merging
: ordinary pages is a more serious problem, since it can cause
: incremental checkpointing to miss modified pages. The zero-page
: case instead produces false positives, causing unnecessary copying.
: 
: It would be worth addressing separately, preserving KSM's internal
: zero-page marker without manufacturing a soft-dirty indication.