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

[Peter Zijlstra]

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
> 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
> __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.

Silly question, why not put the .smp_locks in
__init_begin[],__init_end[] right next to .altinstr such that it gets
freed by free_initmem() ?