From: Peter Zijlstra <peterz@infradead.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
x86@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
open list <linux-kernel@vger.kernel.org>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
lkft-triage@lists.linaro.org,
Nathan Chancellor <nathan@kernel.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Anders Roxell <anders.roxell@linaro.org>,
clang-built-linux <llvm@lists.linux.dev>
Subject: Re: next: i386-boot: clang-nightly: failed - intermittently - BUG: unable to handle page fault for address: 000024c0
Date: Wed, 24 May 2023 15:01:04 +0200 [thread overview]
Message-ID: <20230524130104.GR83892@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKwvOdkABkajMqBS=xcHxXUTQGXbTN3tj1GcPqpGgGkmAGLkDA@mail.gmail.com>
On Wed, May 17, 2023 at 11:11:51AM -0700, Nick Desaulniers wrote:
> On Wed, May 17, 2023 at 8:21 AM Naresh Kamboju
> <naresh.kamboju@linaro.org> wrote:
> >
> > Linux next-20230517 build with clang nightly for i386 boot fails intermittently.
>
> Keyword: intermittently. That will make tracking this down fun.
>
> Our CI also hit a boot failure on tip/master with the same splat:
> https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/4998374271/jobs/8957285746
> Though the CI pulled down a SHA
> 0932447780e1f9a43bf68ef7fe3d9b41b46d58fc
> which looks weird on
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=0932447780e1f9a43bf68ef7fe3d9b41b46d58fc
> >> Notice: this object is not reachable from any branch.
Github isn't willing to show me content unless I log in or somesuch
nonsense.
> That this failed in -next and -tip in the same way makes me wonder if
> something affecting this is coming in via -tip? Maybe the splat looks
> familiar to x86 folks?
>
> I haven't been able to reproduce locally when my machine is relatively
> load-less. If I do a kernel build in the background, I was able to
> get QEMU to hang, but without any splat. That was using tip/master @
> f81d8f759e7f.
>
> Naresh, when you say "intermittent" do you have any data on the
> relative frequency of this boot failure? (Also, please make sure to
> use llvm@lists.linux.dev in the future; we moved mailing lists years
> ago).
>
> Looks like our CI report linked above has an additional splat though
> via apply_alternatives and optimize_nops.
>
> >> [ 0.166742] Code: Unable to access opcode bytes at 0x36.
>
> Peter, that smells like perhaps either:
> commit b6c881b248ef ("x86/alternative: Complicate optimize_nops() some more")
> commit 6c480f222128 ("x86/alternative: Rewrite optimize_nops() some")
So I did find me a 'funny' there, but nothing that explains boot fail.
It would think that 'PAUSE' is a 2 byte NOP and replace it with NOP2;
which is not quite the same thing. The below seems to cure that.
Let me continue poking at things...
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 93aa95afd005..bb0a7b03e52f 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -159,9 +160,12 @@ void text_poke_early(void *addr, const void *opcode, size_t len);
*/
static bool insn_is_nop(struct insn *insn)
{
- if (insn->opcode.bytes[0] == 0x90)
+ /* Anything NOP, but not REP NOP. */
+ if (insn->opcode.bytes[0] == 0x90 &&
+ (!insn->prefixes.nbytes || insn->prefixes.bytes[0] != 0xF3))
return true;
+ /* NOPL */
if (insn->opcode.bytes[0] == 0x0F && insn->opcode.bytes[1] == 0x1F)
return true;
next prev parent reply other threads:[~2023-05-24 13:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 15:21 next: i386-boot: clang-nightly: failed - intermittently - BUG: unable to handle page fault for address: 000024c0 Naresh Kamboju
2023-05-17 18:11 ` Nick Desaulniers
2023-05-18 8:36 ` Naresh Kamboju
2023-05-24 13:01 ` Peter Zijlstra [this message]
2023-05-24 18:36 ` Nick Desaulniers
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=20230524130104.GR83892@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=llvm@lists.linux.dev \
--cc=naresh.kamboju@linaro.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=x86@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).