mbox series

[0/4] x86/alternatives: Do NOPs optimization on a temporary buffer

Message ID 20240130105941.19707-1-bp@alien8.de
Headers
Series x86/alternatives: Do NOPs optimization on a temporary buffer |

Message

Borislav Petkov Jan. 30, 2024, 10:59 a.m. UTC 
  From: "Borislav Petkov (AMD)" <bp@alien8.de>

Hi,

here's a small set which sprang out from my reacting to the fact that
NOPs optimization in the alternatives code needs to happen on
a temporary buffer like the other alternative operations - not in-place
and cause all kinds of fun.

The result is this, which makes the alternatives code simpler and it is
a net win, size-wise:

 1 file changed, 50 insertions(+), 72 deletions(-)


Constructive feedback is always welcome!

Thx.

Borislav Petkov (AMD) (4):
  x86/alternatives: Use a temporary buffer when optimizing NOPs
  x86/alternatives: Get rid of __optimize_nops()
  x86/alternatives: Optimize optimize_nops()
  x86/alternatives: Sort local vars in apply_alternatives()

 arch/x86/kernel/alternative.c | 122 ++++++++++++++--------------------
 1 file changed, 50 insertions(+), 72 deletions(-)

Comments

Paul Gortmaker Jan. 31, 2024, 4:17 p.m. UTC | #1 
[[PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer] On 30/01/2024 (Tue 11:59) Borislav Petkov wrote:

> From: "Borislav Petkov (AMD)" <bp@alien8.de>
> 
> Hi,
> 
> here's a small set which sprang out from my reacting to the fact that
> NOPs optimization in the alternatives code needs to happen on
> a temporary buffer like the other alternative operations - not in-place
> and cause all kinds of fun.
> 
> The result is this, which makes the alternatives code simpler and it is
> a net win, size-wise:
> 
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> 
> Constructive feedback is always welcome!

So, I figured I would set up the same reproducer, on the same machine;
build and test a known broken NOP rewrite kernel like v6.5.0 to confirm
I could still reproduce the boot fail in approximately 2% of runs.  And
then move to testing this series.

Well, much to my annoyance my plan broke down at step one.  After about
three hours and over 400 runs, I didn't get a single fail. I still had a
known broken build from the original reporting in October of v6.5.7, so
I let that run for over 300 iterations, and also didn't get any
failures.

I have to assume that even though I'm using the same host, same scripts,
that because I was testing on Yocto master, other things have changed
since October - maybe binutils, qemu, the runqemu script,  ...  In
theory, I could try and reset Yocto back to October-ish but that is
probably of diminishing returns.  And I can't unwind the host machine
distro updates that have happened since October.

With hindsight and knowledge of what the issue was and how narrow the
window was to trigger it, I guess this shouldn't be a surprise.

So as a "next best" effort, I let this rc1-alt-v2 branch run overnight,
and after over 2200 iterations, I didn't get any boot fails.

Paul.
--

> 
> Thx.
> 
> Borislav Petkov (AMD) (4):
>   x86/alternatives: Use a temporary buffer when optimizing NOPs
>   x86/alternatives: Get rid of __optimize_nops()
>   x86/alternatives: Optimize optimize_nops()
>   x86/alternatives: Sort local vars in apply_alternatives()
> 
>  arch/x86/kernel/alternative.c | 122 ++++++++++++++--------------------
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> -- 
> 2.43.0
>
Borislav Petkov Jan. 31, 2024, 4:25 p.m. UTC | #2 
On Wed, Jan 31, 2024 at 11:17:27AM -0500, Paul Gortmaker wrote:
> So as a "next best" effort, I let this rc1-alt-v2 branch run overnight,
> and after over 2200 iterations, I didn't get any boot fails.

Thanks a lot!

As mentioned on IRC yesterday, the important thing is that this doesn't
break any of your guests. And that is good enough.

Much appreciated, thanks again!