[RFC] mm: Is flush_cache_page() in wp_page_reuse() really necessary?

["wuyifeng (C)" <wuyifeng10@huawei.com>]

[Forwarded] This is the email I previously sent to the maintainer.
I forgot to copy the mailing list, so I am resending it here.


-------- 转发的消息 --------
主题: [RFC] mm: Is flush_cache_page() in wp_page_reuse() really necessary?
日期: Mon, 29 Sep 2025 15:29:37 +0800
From: wuyifeng (C) <wuyifeng10@huawei.com>
收件人: David Hildenbrand <david@redhat.com>, akpm@linux-foundation.org, lorenzo.stoakes@oracle.com
抄送: baohua@kernel.org

Hi Linux MM developers,

I am reviewing the page fault handling code in the memory management
subsystem and came across a point that puzzled me regarding the use of
flush_cache_page().

When I referred to Documentation/core-api/cachetlb.rst, it describes a
typical sequence in a page fault scenario:

flush_cache_page(vma, addr, pfn);
set_pte(pte_pointer, new_pte_val);
flush_tlb_page(vma, addr);


That is, first the CPU cache is flushed, then the PTE is updated, and
finally the TLB is flushed for the corresponding virtual address. This
makes sense: when the virtual-to-physical mapping changes, flushing the
CPU cache is necessary to prevent stale or corrupted cache from affecting
the new mapping.

However, in wp_page_reuse(), the virtual-to-physical mapping does
not change. The function looks like this:

static inline void wp_page_reuse(struct vm_fault *vmf)
{
    struct vm_area_struct *vma = vmf->vma;
    struct page *page = vmf->page;
    pte_t entry;

    if (page)
        page_cpupid_xchg_last(page, (1 << LAST_CPUPID_SHIFT) - 1);

    flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte));
    entry = pte_mkyoung(vmf->orig_pte);
    entry = maybe_mkwrite(pte_mkdirty(entry), vma);
    if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
        update_mmu_cache(vma, vmf->address, vmf->pte);
}


Since the mapping itself does not change, I am puzzled whether this
flush_cache_page() call is actually necessary.

A similar situation appears in do_huge_pmd_wp_page(), which handles
huge pages. When the system reaches the reuse branch after the relevant
checks, the code looks like this:

reuse:
	entry = pmd_mkyoung(orig_pmd);
	entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma);
	if (pmdp_set_access_flags(vma, haddr, vmf->pmd, entry, 1))
		update_mmu_cache_pmd(vma, vmf->address, vmf->pmd);


Here, flush_cache_page() is not called. Instead, the code relies on
updating PMD access flags and calling update_mmu_cache_pmd() to refresh
the TLB.

I have traced this back to the 2.6 kernel, and observed that the
`flush_cache_page` interface has already been present in the
reuse-related logic since then.

It appears that this part has not
received much attention over time, and the invocation of
`flush_cache_page` here may indeed be redundant?

code in do_wp_page (linux 2.6):
	/* reuse the old page */
	if (PageAnon(old_page) && !TestSetPageLocked(old_page)) {
		int reuse = can_share_swap_page(old_page);
		unlock_page(old_page);
		if (reuse) {
			flush_cache_page(vma, address, pfn);
			entry = maybe_mkwrite(pte_mkyoung(pte_mkdirty(pte)),
					      vma);
			ptep_set_access_flags(vma, address, page_table, entry, 1);
			update_mmu_cache(vma, address, entry);
			lazy_mmu_prot_update(entry);
			pte_unmap(page_table);
			spin_unlock(&mm->page_table_lock);
			return VM_FAULT_MINOR|VM_FAULT_WRITE;
		}
	}

So my questions are:

Is the flush_cache_page() call in wp_page_reuse() actually
necessary?

If it is necessary, why is flush_cache_page() not required in the
reuse branch of do_huge_pmd_wp_page() for huge pages?

I would greatly appreciate your reply. Thank you very much!

Best regards,
[wuyifeng]