Re: [PATCH 1/4] mm/sparse-vmemmap: map shared vmemmap tail pages as read-only

On Oct 21, 2026, at 12:57, Lance Yang [off-list ref] wrote:


On Mon, Oct 19, 2026 at 05:08:27PM +0800, Muchun Song wrote:

quoted

Both early HugeTLB HVO and device DAX use the common vmemmap population
path for shared tail mappings. Map these pages read-only so that illegal
writes fault instead of corrupting metadata shared by multiple tail
pages.

For early HugeTLB, this moves existing write protection into initial
population without changing the final mapping. Device DAX gains the same
protection.

Signed-off-by: Muchun Song <redacted>
---
Documentation/mm/vmemmap_dedup.rst | 3 +--
mm/sparse-vmemmap.c                | 3 +++
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst
index 8c287ae3f86c..76f903975a40 100644
--- a/Documentation/mm/vmemmap_dedup.rst
+++ b/Documentation/mm/vmemmap_dedup.rst

@@ -193,5 +193,4 @@ There's no remapping of vmemmap given that device-dax memory is not part of

System RAM ranges initialized at boot. Thus the tail page deduplication
happens at a later stage when we populate the sections.

-Deduplicated tail pages are not mapped read-only. The mapping layout is the same
-as HugeTLB.
+The mapping layout is the same as HugeTLB.

diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 40eba70c0048..ba0496daf4de 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c

@@ -295,6 +295,9 @@ static pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, in

return NULL;

	entry = pfn_pte(PHYS_PFN(__pa(p)), PAGE_KERNEL);
+ 	/* Map the shared tail page as read-only to catch illegal writes. */
+ 	if (vmemmap_optimizable_pfn(pfn))
+ 		entry = pte_wrprotect(entry);

LLM pointed out that an AO MCE before bootmem gather could still reach
TestSetPageHWPoison() on a shared tail, since the head isn't marked
hugetlb yet.

Compared with the RO problem, a more serious issue may be
that the struct page has not yet been initialized, and the
MCE preprocessing flow may all be problematic, performing
various operations based on an uninitialized struct page.
However, this problem is not specific to hugetlb; the same
problem exists when CONFIG_DEFERRED_STRUCT_PAGE_INIT is
enabled.

Wouldn't that trigger an Oops ... Anyway, I wouldn't expect to hit that
during boot.

Therefore, I do not think this kind of problem during the boot
stage is a problem, because we have no way to prevent it.

Reviewed-by: Lance Yang <lance.yang@linux.dev>

THanks.

[...]

Cheers, Lance