Messages in this thread | | | Date | Mon, 31 Oct 2022 13:56:30 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] x86/alternative: Consistently patch SMP locks in vmlinux and modules |
| |
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@oracle.com> > ---
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@infradead.org>
| |