Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks
From: Waiman Long
Date: Mon May 11 2026 - 00:56:02 EST
On 5/10/26 11:02 AM, Mike Rapoport wrote:
Hi Waiman,
On Tue, May 05, 2026 at 01:18:21AM -0400, Waiman Long wrote:
When testing a v7.1 kernel with commit 59bd1d914bb5 ("memblock: warn whenBefore 59bd1d914bb5 it was a silent leak. housekeeping_init() is called
freeing reserved memory before memory map is initialized"), the following
warning was hit when there was a "nohz_full" kernel boot parameter.
[ 0.080911] Cannot free reserved memory because of deferred initialization of the memory map
[ 0.080911] WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0
:
[ 0.080945] Call Trace:
[ 0.080947] <TASK>
[ 0.080949] memblock_phys_free+0xcb/0x100
[ 0.080953] housekeeping_init+0x14c/0x170
[ 0.080957] start_kernel+0x207/0x450
[ 0.080961] x86_64_start_reservations+0x24/0x30
[ 0.080965] x86_64_start_kernel+0xda/0xe0
[ 0.080967] common_startup_64+0x13e/0x141
[ 0.080972] </TASK>
The commit states that freeing of reserved memory before the memory
map is fully initialized in deferred_init_memmap() would cause access
to uninitialized struct pages and may crash when accessing spurious
list pointers. However, if the memblock_free() call is deferred to
the start of initcall processing in the bootup process, for instance,
the following KASAN warning can appear.
[ 8.514775] BUG: KASAN: use-after-free in memblock_isolate_range+0x4ac/0x650
[ 8.514775] Read of size 8 at addr ffff88a07fe6a000 by task swapper/0/1
:
[ 8.514775] Call Trace:
[ 8.514775] <TASK>
[ 8.514775] kasan_report+0xb2/0x1b0
[ 8.514775] memblock_isolate_range+0x4ac/0x650
[ 8.514775] memblock_phys_free+0xc4/0x190
[ 8.514775] housekeeping_late_init+0x257/0x280
[ 8.514775] do_one_initcall+0xaa/0x470
[ 8.514775] do_initcalls+0x1b4/0x1f0
[ 8.514775] kernel_init_freeable+0x4b5/0x550
[ 8.514775] kernel_init+0x1c/0x150
[ 8.514775] ret_from_fork+0x5dc/0x8e0
[ 8.514775] ret_from_fork_asm+0x1a/0x30
[ 8.514775] </TASK>
It is likely that memblock_discard() may discard memblock data needed
for memblock_free(). One workaround for now to avoid these warning/bug
messages is to keep the memblock allocated cpumasks even if they are
no longer needed until the memblock subsystem is properly updated to
handle memblock_free().
On most systems, memory occuipied by a cpumask is pretty small. So not
much memory will be wasted if the memblock cpumasks are not freed.
Signed-off-by: Waiman Long <longman@xxxxxxxxxx>
---
kernel/sched/isolation.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index ef152d401fe2..ad9b1a1104e3 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -189,7 +189,13 @@ void __init housekeeping_init(void)
WARN_ON_ONCE(cpumask_empty(omask));
cpumask_copy(nmask, omask);
RCU_INIT_POINTER(housekeeping.cpumasks[type], nmask);
- memblock_free(omask, cpumask_size());
+
+ /*
+ * TODO: Don't free memblock allocated cpumasks until the
+ * memblock subystem is able to handle the memblock_free()
+ * properly.
+ */
+ // memblock_free(omask, cpumask_size());
after memblock moves all the memory to buddy, so this would only update
memblock.reserved.
The comment a few lines above says that we reallocate to be able to kfree()
later. Is it possible to delay reallocation until an initcall?
My original thought was to defer the freeing to init call. That changes led to the KASAN bug splat listed in the commit log, I think the right window to free memblock memory is currently just too narrow. Do you mean that with the fix patch you sent to Breno, memblock freeing in initcall will work without bug report? If so, I can send another patch to defer memblock freeing after the fix patch is merged as the KASAN bug is more serious than the memblock warning. I will do some testing tomorrow with your fix patch.
Cheers,
Longman