On Wed, May 24, 2023 at 6:01 AM Peter Zijlstra peterz@infradead.org wrote:
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/4998... 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=09324...
Notice: this object is not reachable from any branch.
Github isn't willing to show me content unless I log in or somesuch nonsense.
Ah, sorry about that. https://paste.debian.net/1281050/ should be the log of ours. https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/... is the corresponding build artifact.
There's ongoing discussion in #x86 on LinuxNet. I suspect that a few of Naresh's recent reports are all perhaps one single issue.
Arnd mentioned https://lore.kernel.org/all/CA+G9fYvVZ9WF-2zfrYeo3xnWNra0QGxLzei+b4yANZwEvr5... which looks similar but is with GCC.
Either way, we're seeing this in mainline.
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;