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

[Mike Rapoport <rppt@kernel.org>]

On Mon, Feb 16, 2026 at 03:53:33PM +1100, Benjamin Herrenschmidt wrote:
> (stripping history)
> 
> So I went into a big refresher (or learning exercise since there's
> quite a bit here that I never really looked at before either).
> 
> So here is a break down, in chronological order, of the setup and
> initialization of the memory map, and how the reserve business
> interacts with it as I understand it from reading the code.
> 
> Please correct me if I missed or misunderstood something :-) 

Your description is correct. There are some things that moved from arch to
mm_core_init() just recently, but the order remains the same.

> Also maybe this is worth turning into a piece of doc ?

Care to send a patch? ;-)
 
> Then some conclusions (I think I know why the patches crashed).
 
(trimmed down the description)
 
>  * One thing I have NOT yet figured out ... do we have a problem if the
> page is in a hole that lands outside of a zone boundary ? I haven't
> really got my head deep down into the details of zone initializations
> (especially as we adjust the boundaries here or there), so this could
> be a problem.

Zones boundaries are determined by addressing constraints (DMA, DMA32,
NORMAL), node assignment and actual usable memory in memblock.memory.

For a machine like t3a.nano there will be ZONE_DMA up to 16M and ZONE_DMA32
from 16M till the end of the usable memory so there should be no problem
there :)

In the general case, I believe it is possible that some reserved memory
will not be covered by a zone, for example if the reserved memory is beyond
the end of the last zone.

I think that this is a really pathological case and we can dismiss it for
now. 
 
> 99) Conclusion :-)
> ------------------
> 
> Nothing firm yet here but a few hints at what could possibly go wrong
> and one obvious issue with the previous patch(es).
> 
> First the obvious ... the proposed patch that just makes
> memblock_free_late() call free_reserved_page() is missing a call to
> pfn_valid(). Without this, it can (and will) hit holes in the mem_map,
> and that's probably one of the crashes I reported.

It can, not sure it will, but we want to stay on the safe side :)
 
> Now, it would be nice to then go allocate those missing bits of
> mem_map, because I really don't want to give up on that memory. Small
> instances are a thing and with the current price of DRAM, a fairly
> relevant one :-) But I'll look at that later.
> 
> My original patch had the exact same issue btw.
> 
> The other potential issue, for which I welcome your input as I'm
> running short on time for the day is ... the impact to zones. I see a
> possibility for those pages to be outside of any zone's
> zone_start_pfn/spanned_pages range ... or not ? As I said, I didn't get
> my head yet around the zones init and spanning adjustments that
> happens, so I don't know if we really have potentially "holes" here or
> not.
> 
> This leads to the question... could we work around a lot of those
> issues easily by making the early efi_reserve_boot_services() *also*
> add the regions to memblock.memory in addition to memblock.reserve ?
> ie, those regions are marked as boot services code/data, so they must
> be memory to begin with, and that's all early enough that we can do it.

Adding the EFI boot services to memblock.memory would certainly solve both
potentially missing memory map and (unlikely) missing zone span.

More broadly, it would have been nice if e820/efi would add *anything* that
lives in DRAM to memblock.memory, but last time I tried I could not
convince x86 folks that even memory that's unusable to kernel is still
memory :)
 
> We should still add the missing pfn_valid() of course, if anything for
> the sake of any other caller of memblock_free_late() ... or we could
> change memblock_free_late() to only consider ranges that are both
> reserved *and* in memblock.memory. You mentioned that might be slow
> though.

memblock_free_late() can't consider memblock.memory and memblock.reserved
because it might be called after they were discarded. 
And pfn_valid() should protect against accesses to non-existent memory map.
 
> Opinions ?
> 
> Cheers,
> Ben.

-- 
Sincerely yours,
Mike.