Re: [RFC 0/7] mm: dual-bitmap page allocator consistency checker

[Sasha Levin]

On Fri, Apr 24, 2026 at 04:34:12PM +0100, Matthew Wilcox wrote:
> On Fri, Apr 24, 2026 at 10:00:49AM -0400, Sasha Levin wrote:
> > corruption must be detected before it propagates. The dual-bitmap
> > implements a way to protect from corruption coming from hardware or
> > software - two complementary representations of page allocation state,
> > allocated independently via memblock, where any single-bit fault in
> > either bitmap is immediately detectable. Performance is secondary to
> > correctness in this context. A safety mechanism must be simple enough
> > to audit and certify, must fail deterministically (panic, not
> > log-and-hope), and its correctness matters more than its throughput.
> > The dual-bitmap adds two atomic bitops per alloc/free, but for
> > safety-critical deployments this cost is acceptable because the
> > alternative - undetected corruption propagating silently - violates
> > the system's safety case. The static key ensures zero cost for kernels
> > that don't need it.
>
> But doubling the storage requirement in order to achieve merely detection
> is significantly worse than state-of-the-art in 1950 (when Richard
> Hamming invented Hamming codes).  If we used a (7,3) code, we'd have
> SECDED at a lower cost.  Of course, there are far better codes available
> than that today.

I agree with the density concern. I have two reasons for that:

1. Update cost. On the alloc/free hot path the dual-bitmap update is two
independent test_and_set_bit. A Hamming/SECDED codeword needs a
read-modify-write of the whole word with locking on every state change.

2. Correlated faults. The two copies need to sit in different physical memory
so a multi-bit fault (row, column, bank, row-hammer) can only hit one of them.
See this paper which has some numbers:
https://dl.acm.org/doi/epdf/10.1145/2786763.2694348 - About 21% of DRAM faults
span more than one bit, plain SECDED can leave up to 20 FIT per device of
undetected errors from those, and it only helps at all if data and parity bits
are spread across physically separate cells.

Two memblock_alloc'd bitmaps give that separation for free. You could
interleave a code across two independent regions instead, but then
the invariant check stops being a one-line complement check, which is
what I was trying to keep simple for the audit side.

--
Thanks,
Sasha