Re: [PATCHv7 13/18] mm: Drop fake head checks

[Muchun Song]

> On Oct 27, 2026, at 20:31, Kiryl Shutsemau <kas@xxxxxxxxxx> wrote:
> 
> On Tue, Oct 27, 2026 at 01:05:58PM +0100, David Hildenbrand (Arm) wrote:
>>> Writing this, I just realized that we have another option -- map the
>>> shared tail page writable. A failing LOCK CMPXCHG writes back the value
>>> it read, and the get never changes a zero refcount, so the race becomes
>>> harmless. The cost is the protection: the page is shared by every
>>> hugetlb folio of that order in the zone, so a stray write to any tail
>>> silently corrupts all of them instead of oopsing.
>> 
>> Right. Without HVO we would just corrupt pages in the single folio (which is
>> also not nice).
>> 
>> I'm also questioning whether we need this RO protection all the time active.
> 
> What do you have in mind? RO only under a debug option, or switching the
> tail page to RO some time after the remap?

I don't think enabling RO only on debug kernels is a good choice.

Within ByteDance, we once successfully caught memory failures using RO (because
we backported HVO, but some missing commits in memory failure caused write
operations on tail pages to persist). These operations triggered invalid writes
to shared tail pages.

Under the old HVO schema, this invalid write only corrupted one folio, but under
the new schema, it corrupts all HVOed folios. Therefore, I personally believe
that for the new schema, the value of RO is even greater.

Thanks,
Muchun

> 
> If it is the delay, a grace period alone does not close the race. We
> would need rcu_read_lock() back around the get, and then it is the old
> scheme with the wait taken off the allocation path.
> 
> -- 
>  Kiryl Shutsemau / Kirill A. Shutemov