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

[Mike Rapoport]

On Sat, Mar 28, 2026 at 12:41:18PM +0100, Borislav Petkov wrote:
> On Sat, Mar 28, 2026 at 11:16:34AM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@xxxxxxxxxx>
> > 
> > On UP systems alternative_instructions() frees memory occupied by smp_locks
> 
> UP systems?
> 
> I don't understand - Bert's machine is a SMP.

Argh, I misread the 'if (!uniproc_patched' :(
 
> > section immediately after patching the lock instructions.
> > 
> > With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled this happens before the
> > memory map is fully initialized and the struct pages representing the freed
> > memory might get overwritten by deferred initialization of the memory map.
> > 
> > Move freeing of smp_locks section to an initcall to ensure it will happen
> > after the memory map is fully initialized.
> > 
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> > Tested-By: Bert Karwatzki <spasswolf@xxxxxx>
> 
> I don't understand even more: why have we not hit this before?

That memory was never actually freed, it remained reserved because
free_init_pages() calls free_reserved_area() but does not update memblock.
 
> No Fixes: tag?

It's as old as CONFIG_DEFERRED_STRUCT_PAGE_INIT (v4.2) or even before that.
If you think that fixing this leak is important enough to backport, it
affects all mainlined stable releases.

> Something must've changed for this to fire...

Yes, I added a WARN() in free_reserved_area() to lure such cases and
prevent them in the future.

I'll wait a bit for more comments before rewriting changelog and reposting.

> -- 
> Regards/Gruss,
>     Boris.

-- 
Sincerely yours,
Mike.