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

[Sasha Levin]

On Sat, Apr 25, 2026 at 07:51:10AM +0200, David Hildenbrand (Arm) wrote:
> On 4/24/26 18:25, Sasha Levin wrote:
> > On Fri, Apr 24, 2026 at 05:42:53PM +0200, Vlastimil Babka (SUSE) wrote:
> > > On 4/24/26 16:00, Sasha Levin wrote:
> > > > Existing memory debugging tools - KASAN, KFENCE, page_poisoning - detect
> > > > access violations and content corruption, but none of them can detect
> > > > silent corruption in the page allocator's own metadata. If a hardware
> > > > bit flip corrupts an allocation bitmap, the allocator hands out a page
> > >
> > > An allocation what? The page allocator is a buddy allocator, it has no
> > > bitmap to track free/allocated state of pages?
> >
> > You're right, the cover letter is misleading there. Buddy doesn't use a bitmap:
> > PageBuddy lives in page_type, the free list is a list, and page->private holds
> > the order. The dual-bitmap is new metadata the feature adds, maintained from
> > the alloc/free hooks.
>
> Given that you have PageBuddy (first "bit"), could we use a second bit in page_ext?

Hmm... Thats an interesting idea.

I can see two concerns with something like this:

1. The checker has to be live before memblock_free_all() hands pages to buddy.
page_ext isn't fully up that early I think.

2. page_type encodes buddy, offline, slab tags, etc... and a page that isn't
PageBuddy isn't necessarily allocated through alloc_pages. The invariant gets
case-y.

But let me think about it a bit more.

--
Thanks,
Sasha