Re: [PATCH v2] x86/alternative: Consistently patch SMP locks in vmlinux and modules

[Peter Zijlstra]

On Thu, Oct 27, 2022 at 10:49:06PM +0200, Julian Pidancet wrote:
> The alternatives_smp_module_add() function restricts patching of SMP
> lock prefixes to the text address range passed as an argument.
> 
> For vmlinux, patching all the instructions located between the _text and
> _etext symbols is allowed. That includes the .text section but also
> other sections such as .text.hot and .text.unlikely.
> 
> As per the comment inside the 'struct smp_alt_module' definition, the
> original purpose of this restriction is to avoid patching the init code.

Urgh.. so yes. We patch before releasing .init stuff, *however* this
thing has a mode where it can change it's mind dynamically. That is, if
you boot with just a single CPU and then later do CPU hotplug to bring
another CPU online, it will quickly scribble the LOCK prefixes back in.

And at *that* time it is important to not scribble .init -- because
obviously, it'll be gone by then.

> For modules, the current code only allows patching instructions located
> inside the .text segment, excluding other sections such as .text.hot or
> .text.unlikely, which may need patching.
> 
> Make patching of the kernel core and modules more consistent, by
> allowing all text sections of modules except .init.text to be patched in
> module_finalize().
> 
> For that, use mod->core_layout.base/mod->core_layout.text_size as the
> address range allowed to be patched, which include all the code sections
> except the init code.
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@xxxxxxxxxx>
> ---

So while I was initially thinking you could just remove all that
'skip-init' stuff and simplify this code, alas you can't without also
taking out that whole uniproc_patched case (which I woudln't mind fwiw).

As such; this is indeed the minimal patch to make things consistent.

Acked-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>