Re: [Bug 221804] New: WARNING at mm/memblock.c:904 __free_reserved_area(): "Cannot free reserved memory because of deferred initialization of the memory map" during housekeeping_init() at boot

[Mike Rapoport <rppt@kernel.org>]

On Tue, Jul 28, 2026 at 01:40:16PM -0700, Andrew Morton wrote:
> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Tue, 28 Jul 2026 15:52:54 +0000 bugzilla-daemon@kernel.org wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=221804
> > 
> >             Bug ID: 221804
> >            Summary: WARNING at mm/memblock.c:904 __free_reserved_area():
> >                     "Cannot free reserved memory because of deferred
> >                     initialization of the memory map" during
> >                     housekeeping_init() at boot
> >            Product: Memory Management
> >            Version: 2.5
> >           Hardware: All
> >                 OS: Linux
> >             Status: NEW
> >           Severity: normal
> >           Priority: P3
> >          Component: Other
> >           Assignee: akpm@linux-foundation.org
> >           Reporter: ionut.nechita@windriver.com
> >         Regression: No
> > 
> > Hello Kernel Team,
> > 
> > I notice this today:
> > 
> > ...
> > [    0.075447] Dynamic Preempt: lazy
> > [    0.075489] ------------[ cut here ]------------
> > [    0.075490] Cannot free reserved memory because of deferred initialization
> > of the memory map
> 
> Thanks.  I asked Gemini "what happened here" and the response was
> illuminating.
> 
> The bottom lines:
> 
> 
> The Core Issue: Initialization Order Conflict
> 
>   The kernel hit an order-of-operations conflict between memory setup
>   and kernel parameter parsing:
> 
>   CONFIG_DEFERRED_STRUCT_PAGE_INIT=y delays initializing struct page
>   tracking structures for large pools of RAM until secondary CPUs come
>   online (to speed up boot times on large systems).
> 
>   housekeeping_init() runs very early during start_kernel().  It
>   parses CPU isolation/housekeeping flags (isolcpus=, nohz_full=,
>   rcu_nocbs=) and allocates temporary cpumask buffers in memblock. 
>   Once parsed, it tries to free those temporary buffers back to the
>   memory pool using memblock_phys_free().
> 
>   The Collision: memblock_phys_free() calls __free_reserved_area(),
>   which requires valid struct page mappings.  Because page
>   initialization was deferred, __free_reserved_area() detects that the
>   target memory's struct page maps aren't ready yet (at time 0.075s,
>   whereas deferred init only finished around 0.325s).

Just to add a bit of a human touch:

housekeeping_setup() allocates the masks from memblock when it parses the
command line before mm_core_init().

housekeeping_init() reallocates them with kmalloc() to allow
consistent kfree() afterwards and frees the memblock allocations.

And since housekeeping_init() happens after page allocator + slab init and
before deferred_memmap_init() we can't reliably memblock_free() the
memblock allocations.
 
> As a safeguard, __free_reserved_area() issues a WARN() and refuses to
> free the pages.
> 
> Fix/Workaround:
> 
>   Fix the nohz_full syntax on the command line (e.g.,
>   nohz_full=8-55,64-111).

I don't see how that will help.
 
>   To eliminate the warning entirely until fixed upstream, boot with
>   deferred_init=off as a kernel parameter

Which does not exist :)

>   or disable CONFIG_DEFERRED_STRUCT_PAGE_INIT in the kernel build.

This would work, but would cost in boot time on a machine with 128 GiB of
RAM.

>   Upstream, housekeeping_init() should either avoid early memblock
>   freeing

Presuming that houskeeping wants to keep the reallocation with kmalloc(),
it should defer freeing to, say, some_initcall(housekeeping_late_init).

And housekeeping_setup() might want to memblock_alloc() enough memory for
all the possible hk_type's once and than free that memory in an initcall.

>   or use allocations that don't depend on fully initialized page
>   maps.

It's really not an option :)
 
> I don't think this is very high priority.

-- 
Sincerely yours,
Mike.