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

[Pasha Tatashin <pasha.tatashin@soleen.com>]

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