* 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
2026-07-28 20:40 ` [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 Andrew Morton
@ 2026-07-29 5:50 ` Mike Rapoport
0 siblings, 0 replies; 2+ messages in thread
From: Mike Rapoport @ 2026-07-29 5:50 UTC (permalink / raw)
To: Andrew Morton
Cc: ionut.nechita, bugzilla-daemon, linux-mm, Frederic Weisbecker
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.
^ permalink raw reply [flat|nested] 2+ messages in thread