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

[Sasha Levin]

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.

What it actually catches is the same PFN being handed out twice before it's
freed, or freed without having been allocated. Not every kind of buddy
corruption shows up that way, but the common bad ones do. Corruption of the
bitmap itself shows up through the complement invariant.

I'll fix the wording in v2.

--
Thanks,
Sasha