Hi David, > On Nov 5, 2026, at 18:33, David Hildenbrand (Arm) <[email protected]> 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
