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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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 ?

Or am I missing a piece of the puzzle ?

Cheers,
Ben.