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

[Sasha Levin <sashal@kernel.org>]

On Sat, Apr 25, 2026 at 07:30:56AM +0200, David Hildenbrand (Arm) wrote:
>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?

Ideally completely different DIMMs (though as you point out later, we can't
easily make this happen).

>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.

Right, I think that the approach you proposed is roughly equivalent spatially
(though I'd need to check with the safety folks here).

>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?
>???

The notes I have from the research side of things (which should be taken with a
grain of salt) are something along the lines of:

  - ~79% are a single bit corruption
  - ~9% are row faults, so multiple bit corruption within ~8kb
  - ~4% are bank faults, so multiple bit corruption within ~512mb

Obviously the numbers would be very different depending on usecase, hardware,
physical location (did you know bits are more likely to flip in higher
altitudes?)...

>"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?

For something like a datacenter deployment I'd agree with you - the odds are
too low to care. For an unsupervised self driving vehicle, where there's no
human (locally or remotely) available to take over, I'd like the odds to be as
low as possible :)

>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 :)

-- 
Thanks,
Sasha