Re: [PATCH v2] mm: Fix memblock_free_late() when using deferred struct page

[Mike Rapoport <rppt@kernel.org>]

On Wed, Feb 18, 2026 at 11:15:59AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2026-02-18 at 08:47 +1100, Benjamin Herrenschmidt wrote:
> > There is definitely something fishy going on, though I don't know what,
> > as the page is reserved so it should *not* be touched by the deferred
> > initialization... Could there be an issue by which we incorrectly go
> > look at the head page (which hasn't been initialized) of a *potential*
> > compound/huge page ?
> 
> So ... not 100% certain but I see this in __free_one_page():
> 
> 
>   buddy = find_buddy_page_pfn(page, pfn, order, &buddy_pfn);
> 
> Then goes do things with the buddy. find_buddy_page_pfn() is
> (stripping comments):
> 
> static inline unsigned long
> __find_buddy_pfn(unsigned long page_pfn, unsigned int order)
> {
> 	return page_pfn ^ (1 << order);
> }
> 
> static inline struct page *find_buddy_page_pfn(struct page *page,
> 			unsigned long pfn, unsigned int order, unsigned long *buddy_pfn)
> {
> 	unsigned long __buddy_pfn = __find_buddy_pfn(pfn, order);
> 	struct page *buddy;
> 
> 	buddy = page + (__buddy_pfn - pfn);
> 	if (buddy_pfn)
> 		*buddy_pfn = __buddy_pfn;
> 
> 	if (page_is_buddy(page, buddy, order))
> 		return buddy;
> 	return NULL;
> }
> 
> Now what happens if order is 0, page_pfn is a reserved page whose
> "buddy" isn't reserved ... and whose struct page is not initialized
> yet due to deferral ?
> 
> Unless I'm mistaken, we are going to poke around at uninitialized
> struct pages and things can go anywhere from there, can't they ?

It's possible.
 
> Or am I missing a piece of the puzzle ?

Apparently we do miss some piece of the puzzle, otherwise you'd see no
crashes :)

I think an easy and backportable fix would be to make
efi_free_boot_services() an initcall, so that it will surely run after
deferred pages are initialized.
And since the boot services memory is not memblock_alloc()ed but rather
memblock_reserve()ed, it should be freed with free_reserved_area().

With the symptom fixed, we can audit memblock_free_late() and
free_reserved_area() callers and see how to make this all less messy and
more robust.
 
> Cheers,
> Ben.
> 

-- 
Sincerely yours,
Mike.