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

[Sasha Levin]

On Fri, Apr 24, 2026 at 08:28:14PM +0200, David Hildenbrand (Arm) wrote:
> On 4/24/26 17:06, Pasha Tatashin wrote:
> > On 04-24 10:49, Sasha Levin wrote:
> > > On Fri, Apr 24, 2026 at 04:25:41PM +0200, David Hildenbrand (Arm) wrote:
> > > > One bitmap that covers all sparse memory available at boot.
> > > >
> > > > Conclusion: Just horrible.
> > >
> > > Depends on who's looking at the code :)
> > >
> > > I picked it for auditability: covering the whole range with two
> > > memblock_alloc'd arrays means the only thing on the lookup path is the bitmap
> > > words themselves, which is what the dual-bitmap invariant already checks.
> >
> > 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.
> >
> > > We could go with per-section bitmaps which will fix the waste but pull
> > > mem_section[] into the trust boundary, so we'd have to start validating it too.
> >
> > 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.

--
Thanks,
Sasha