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

[Waiman Long]

On 5/6/26 9:25 AM, Valentin Schneider wrote:
> On 05/05/26 01:18, 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>
> Darn, I just saw the previous version doing this.
>
> > 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().
> Pardon my ignorance, but how come this isn't the case for the other
> memblock users? It sounds like there is no right place for freeing this
> mask.

My current thought is to chain all the memblock memory blocks to be 
freed in a singly linked list first and then freed them at the right 
moment by the memblock code. That will require some more investigation 
into the memblock code. This patch is just a temporary workaround which 
I hope will be reverted in the future.

Cheers,
Longman