Re: [PATCH v2] x86/alternative: delay freeing of smp_locks section

[Borislav Petkov]

On Mon, Mar 30, 2026 at 10:10:00PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@xxxxxxxxxx>
> 
> On SMP systems alternative_instructions() frees memory occupied by
> smp_locks section immediately after patching the lock instructions.
> 
> The memory is freed using free_init_pages() that calls free_reserved_area()
> that essentially does __free_page() for every page in the range.
> 
> Up until recently it didn't update memblock state so in cases when
> CONFIG_ARCH_KEEP_MEMBLOCK is enabled (on x86 it is selected by
> INTEL_TDX_HOST), the state of memblock and the memory map would be
> inconsistent.
> 
> Additionally, with CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled feeing of

						      enabled, freeing of...

> smp_locks happens before the memory map is fully initialized and freeing
> reserved memory may case an access to not-yet-initialized struct page when

		  may cause 

> __free_page() searches for a buddy page.
> 
> Following the discussion in [1], implementation of memblock_free_late() and
> free_reserved_area() was unified to ensure that reserved memory that's
> freed after memblock transfers the pages to the buddy allocator is actually
> freed and that the memblock and the memory map are consistent. As a part of
> these changes, free_reserved_area() now WARN()s when it is called before
> the initialization of the memory map is complete.
> 
> The memory map is fully initialized in page_alloc_init_late() that
> completes before initcalls are executed, so it is safe to free reserved
> memory in any initcall except early_initcall().
> 
> Move freeing of smp_locks section to an initcall to ensure it will happen
> after the memory map is fully initialized. Since it does not matter which
> exactly initcall to use and the code lives in arch/, pick arch_initcall.
> 
> [1] https://lore.kernel.org/all/ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@xxxxxxxxxxxxxxxxxxx
> 
> Reported-By: Bert Karwatzki <spasswolf@xxxxxx>
> Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-lkp/202603302154.b50adaf1-lkp@xxxxxxxxx
> Tested-By: Bert Karwatzki <spasswolf@xxxxxx>
> Link: https://lore.kernel.org/r/20260327140109.7561-1-spasswolf@xxxxxx
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> ---
>  arch/x86/kernel/alternative.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)

Yah, thanks for explaining in the commit message in detail.

With the Fixes: you posted downthread:

Acked-by: Borislav Petkov (AMD) <bp@xxxxxxxxx>

to go through your tree as the issue is tickled by the changes there.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette