Re: [RFC 4/7] mm: add page consistency checker implementation

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/25/26 01:34, Sasha Levin wrote:
> On Fri, Apr 24, 2026 at 08:28:14PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/24/26 17:06, Pasha Tatashin wrote:
>>>
>>> The issue is that we are going back in time to a flat memory,
>>> without NUMA or hotplug support. We need an abstraction that avoids
>>> allocating this memory in enormous contiguous chunks, as thit approach
>>> will not work on modern hardware.
>>>
>>>
>>> Page-ext provides all of these capabilities, but as you described in the
>>> cover letter, it does not meet your requirements. Therefore, I believe
>>> a new abstraction layer is needed.
>>
>> If we decided that we want this (and I am not convinced), we definitely want
>> something that supports sparsity and, in particular, something that support
>> memory hotplug.
> 
> Makes sense. Let me take a few days and see if I can find some middle ground
> here.
> 

"The natural question is why not use page_ext. The key objection from a
safety perspective is that page_ext stores per-page metadata in memory
that is itself subject to the same hardware faults we're trying to
detect. The dual-bitmap approach works because the two bitmaps are
independent allocations - corruption in one is caught by comparison
with the other."

So you want to have two bits per page, whereby both bits come from in dependent
pages I assume?

Storing one bit in page_ext and one bit in page flags would be possible if we
had a spare bit in page flags ...  We could allocate two bitmaps per memory section.

But the real question is: how far away do these bits have to be in memory to be
considered "independent" and not prone to the same corruption?

1 bit?
1 byte?
64 byte?
4096 byte?
???

"Embedding both in page_ext means a single fault could
corrupt both the tracking data and its redundant copy in the same
allocation region."

I might be wrong, but isn't that the case for any such fault, as you don't 100%
know how the DIMM is organized internally?

Do we really expect that a MCE event would, for example, very likely corrupt two
neighboring bits, or two bits in the same byte etc? What are the odds that we care?

It's hard to tell here which part of this work is "too research focused". For
example, if I were to write a paper about that, I would make such claims to make
it sound more complicated than it needs to be :)

-- 
Cheers,

David