Re: [RFC 4/7] mm: add page consistency checker implementation
From: Pasha Tatashin
Date: Fri Apr 24 2026 - 11:07:05 EST
On 04-24 10:49, Sasha Levin wrote:
> On Fri, Apr 24, 2026 at 04:25:41PM +0200, David Hildenbrand (Arm) wrote:
> > > + /*
> > > + * Size bitmaps to cover the full PFN range including any holes.
> > > + * Holes waste a few bits but a flat bitmap keeps the indexing
> > > + * trivial (pfn - min_pfn) and avoids additional data structures
> > > + * that would themselves be subject to corruption. This matches
> > > + * the approach used by pageblock_flags.
> > > + */
> > > + pc_state.min_pfn = PHYS_PFN(memblock_start_of_DRAM());
> > > + pc_state.max_pfn = PHYS_PFN(memblock_end_of_DRAM());
> > > + spanned_pfns = pc_state.max_pfn - pc_state.min_pfn;
> > > + if (!spanned_pfns || spanned_pfns > UINT_MAX) {
> > > + pr_err("PFN span %lu cannot be represented by bitmap APIs, feature disabled\n",
> > > + spanned_pfns);
> > > + return;
> > > + }
> > > +
> > > + pc_state.db.nbits = spanned_pfns;
> > > +
> > > + bitmap_bytes = BITS_TO_LONGS(pc_state.db.nbits) * sizeof(unsigned long);
> > > +
> > > + pr_info("Initializing: PFN range [%lu-%lu), %u bits (%zu KB per bitmap)\n",
> > > + pc_state.min_pfn, pc_state.max_pfn, pc_state.db.nbits,
> > > + bitmap_bytes / 1024);
> > > +
> > > + /* Allocate primary bitmap (zeroed by memblock_alloc) */
> > > + pc_state.db.bitmap[DUAL_BITMAP_PRIMARY] =
> > > + memblock_alloc(bitmap_bytes, SMP_CACHE_BYTES);
> > > + if (!pc_state.db.bitmap[DUAL_BITMAP_PRIMARY]) {
> > > + pr_err("Failed to allocate primary bitmap, feature disabled\n");
> > > + return;
> > > + }
> > >
> >
> > 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.
Pasha