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

[Muchun Song]

> On Oct 21, 2026, at 12:57, Lance Yang <lance.yang@xxxxxxxxx> wrote:
> 
> 
> On Mon, Oct 19, 2026 at 05:08:27PM +0800, Muchun Song wrote:
>> 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 <songmuchun@xxxxxxxxxxxxx>
>> ---
>> 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@xxxxxxxxx>

THanks.

> 
> [...]
> 
> Cheers, Lance