Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks

[Waiman Long <longman@redhat.com>]

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 when
>> 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@redhat.com>
>> ---
>>   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());
> Before 59bd1d914bb5 it was a silent leak. housekeeping_init() is called
> 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