[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7C4F08B2-70C1-4A63-B901-33D197A2BDC4@alien8.de>
Date: Tue, 11 Jun 2024 16:05:39 +0200
From: Borislav Petkov <bp@...en8.de>
To: Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...nel.org>
CC: X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 00/14] x86/alternatives: Nest them
On June 11, 2024 3:26:09 PM GMT+02:00, Peter Zijlstra <peterz@...radead.org> wrote:
>On Fri, Jun 07, 2024 at 01:16:47PM +0200, Borislav Petkov wrote:
>
>> Borislav Petkov (AMD) (13):
>> x86/alternative: Zap alternative_ternary()
>> x86/alternative: Convert alternative()
>> x86/alternative: Convert alternative_2()
>> x86/alternative: Convert alternative_input()
>> x86/alternative: Convert alternative_io()
>> x86/alternative: Convert alternative_call()
>> x86/alternative: Convert alternative_call_2()
>> x86/alternative: Convert ALTERNATIVE_TERNARY()
>> x86/alternative: Convert ALTERNATIVE_3()
>> x86/alternative: Convert the asm ALTERNATIVE() macro
>> x86/alternative: Convert the asm ALTERNATIVE_2() macro
>> x86/alternative: Convert the asm ALTERNATIVE_3() macro
>> x86/alternative: Replace the old macros
>>
>> Peter Zijlstra (1):
>> x86/alternatives: Add nested alternatives macros
>>
>> arch/x86/include/asm/alternative.h | 225 +++++++++--------------------
>> arch/x86/kernel/alternative.c | 20 ++-
>> arch/x86/kernel/fpu/xstate.h | 14 +-
>> tools/objtool/arch/x86/special.c | 23 +++
>> tools/objtool/special.c | 16 +-
>> 5 files changed, 125 insertions(+), 173 deletions(-)
>
>The whole back and forth with the n_foo things ia weird, but sure, have
>at.
>
>Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Thanks, yeah it is in the 0th mail:
"For ease of bisection, the old macros are converted to the new, nested
variants in a step-by-step manner so that in case an issue is
encountered during testing, one can pinpoint the place where it fails
easier. Because debugging alternatives is a serious pain."
If you remember, your original patch had this issue where it would confuse two back-to-back .altinstr entries for nested because you were comparing only the offsets and they happened to be equal, by l
Now debugging *that* was insane and I managed to find the issue only when I started converting each place one-by-one and booting each one step.
That's why this superficial split is all about. We will appreciate it later. I hope not but if something explodes, bisection will be a lot easier this way.
I hope this makes sense.
--
Sent from a small device: formatting sucks and brevity is inevitable.
Powered by blists - more mailing lists