Re: [PATCH 0/4] mm: Enforce read-only shared vmemmap tail mappings

[Muchun Song]

Hi David,

> On Nov 5, 2026, at 18:33, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> On 10/19/26 11:08, Muchun Song wrote:
>> This series is split out from the earlier, larger series "mm: Generalize
>> HVO for HugeTLB and device DAX" [1]. While the parent series generalizes
>> vmemmap optimization across HugeTLB and device DAX, this subset addresses
>> a single, self-contained step: mapping shared vmemmap tail pages read-only
>> at population time.
>> 
>> After the previous HugeTLB and device DAX conversions, both can install
>> optimized shared-tail mappings during vmemmap population. These mappings
>> should be read-only because each shared tail vmemmap page backs metadata
>> for many tail pages. HugeTLB applies this protection in a later,
>> subsystem-specific pass, but device DAX currently lacks it.
>> 
>> This series moves the protection into the generic sparse-vmemmap and
>> powerpc radix population paths. This protects device DAX mappings and
>> makes the HugeTLB-specific vmemmap_wrprotect_hvo() pass redundant. With
>> that pass gone, the bootmem-only optimization wrapper has no distinct
>> work and is removed as well.
>> 
>> This is intended to be the fifth smaller step toward the broader HVO
>> generalization. The remaining HVO naming and enablement consolidation is
>> left for follow-up series.
> 
> I assume this patch series is no longer applicable after we remove the RO
> protection for HVO.
> 
> Or am I missing something? :)

Not quite :) The runtime RO part yes, but the vmemmap population path is
a different story — struct page isn't initialized there, so there are no
concurrent accessors and setting RO is safe.

So we can keep it and enjoy the protection RO gives us: if something goes
wrong, we catch it right at the first scene. So I think this series is still
needed.

Thanks,
Muchun

> 
> -- 
> Cheers,
> 
> David