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

[Mike Rapoport <rppt@kernel.org>]

On Mon, Mar 30, 2026 at 09:27:37PM +0200, Peter Zijlstra wrote:
> On Mon, Mar 30, 2026 at 10:10:00PM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> > 
> > 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() ?

Because it's not always freed? :)

-- 
Sincerely yours,
Mike.