All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Borislav Petkov <bp@alien8.de>
Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer
Date: Wed, 31 Jan 2024 11:17:27 -0500	[thread overview]
Message-ID: <Zbpylz6ep3skWF9d@windriver.com> (raw)
In-Reply-To: <20240130105941.19707-1-bp@alien8.de>

[[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
> 

  parent reply	other threads:[~2024-01-31 16:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 10:59 [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer Borislav Petkov
2024-01-30 10:59 ` [PATCH 1/4] x86/alternatives: Use a temporary buffer when optimizing NOPs Borislav Petkov
2024-02-13 15:36   ` [tip: x86/alternatives] " tip-bot2 for Borislav Petkov (AMD)
2024-04-09 17:11   ` tip-bot2 for Borislav Petkov (AMD)
2024-01-30 10:59 ` [PATCH 2/4] x86/alternatives: Get rid of __optimize_nops() Borislav Petkov
2024-02-13 15:35   ` [tip: x86/alternatives] " tip-bot2 for Borislav Petkov (AMD)
2024-04-09 17:11   ` tip-bot2 for Borislav Petkov (AMD)
2024-01-30 10:59 ` [PATCH 3/4] x86/alternatives: Optimize optimize_nops() Borislav Petkov
2024-02-13 15:35   ` [tip: x86/alternatives] " tip-bot2 for Borislav Petkov (AMD)
2024-04-09 17:11   ` tip-bot2 for Borislav Petkov (AMD)
2024-01-30 10:59 ` [PATCH 4/4] x86/alternatives: Sort local vars in apply_alternatives() Borislav Petkov
2024-02-13 15:35   ` [tip: x86/alternatives] " tip-bot2 for Borislav Petkov (AMD)
2024-04-09 17:11   ` tip-bot2 for Borislav Petkov (AMD)
2024-01-31 16:17 ` Paul Gortmaker [this message]
2024-01-31 16:25   ` [PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zbpylz6ep3skWF9d@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.