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

[Muchun Song]

> On Oct 27, 2026, at 21:35, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> On 10/27/26 14:13, Muchun Song wrote:
>> 
>> 
>>> 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:
>>>> 
>>>> 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.
> 
> But would you have caught it with debug setting on in initial rollout / experiments?

Possibly, but we indeed didn't catch it during the testing phase.

The likely reason is that we hadn't anticipated issues in a corner
case like a memory failure. Also, it's worth noting that during our
test and verification phases, actual memory failures simply didn't
occur.

> 
>> 
>> 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.
> But doesn't that mean that you would find serious bugs faster one way or the other?
> 

Good question.

> Silent corruption of any folio state is not good.
> 

Under the new schema, an invalid write causes massive corruption,
which would likely result in an immediate and noticeable failure
(like a crash or oops). From a developer's perspective, this
definitely helps us "fail fast" and find the bug quickly.

So, let me think about what we actually lose without RO.

I believe the main difference is the debuggability of the crash context.
With RO, the hardware intercepts the write immediately and throws
a clear page fault with a call trace. Without RO, an invalid write
silently corrupts memory, and we might only find out later with no
clue where it happened.

Of course, losing this debuggability doesn't seem like a critical
issue after all. Thinking about it this way, restoring RW permissions
to fix this race condition seems like an acceptable trade-off.

Therefore, I am kind of leaning towards removing the RO protection
and restoring RW permissions to solve the race.

Thanks,
Muchun

> -- 
> Cheers,
> 
> David