Created attachment 297081 [details]
dmesg for x86_64 kernel shows no errors on same hardware

Created attachment 297087 [details]
config-huge-5.13.0-rc4-smp

config-huge-5.13.0-rc4-smp

On Mon, May 31, 2021 at 07:21:14PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:

Going by the $subject, please use the below and boot with
"debug-alternative" on the kernel command line.

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 75c752b0628c..9b2cd6b7078b 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -208,8 +208,10 @@ static void __init_or_module noinline optimize_nops(struct alt_instr *a, u8 *ins
 	}
 
 	for (nop = i; i < a->instrlen; i++) {
-		if (WARN_ONCE(instr[i] != 0x90, "Not a NOP at 0x%px\n", &instr[i]))
+		if (WARN_ONCE(instr[i] != 0x90, "Not a NOP at 0x%px\n", &instr[i])) {
+			DUMP_BYTES(instr, a->instrlen, "%px:", instr);
 			return;
+		}
 	}
 
 	local_irq_save(flags);

Some preliminary observations, more fun tomorrow. So I can repro in a
vm, it looks like this below (might wanna stretch your terminal).

In any case, this looks like hv_do_hypercall() in hyperv_init() which
does CALL_NOSPEC and if you look at it closely, you'll see that at
final_insn, at offset 17 decimal there's a NOP (0x90).

But that trips our NOP detection because this is a 32-bit kernel and it
uses the 32-bit version of CALL_NOSPEC which is doing alignment stuff
and *that* the compiler pads with, yap, NOPs.

Which is exactly the thing I was saying it'll never happen because we
can control the make sure there are no NOPs in between instructions.
Except that damn compiler-generated ratpoline.

Oh well, let's talk tomorrow.

 SMP alternatives: feat: 7*32+12, old: (hyperv_init+0x304/0x3d1 (c27fb587) len: 54), repl: (c28cdd8f, len: 54)
 SMP alternatives: c27fb587: old_insn: ff 54 24 0c 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
 SMP alternatives: c28cdd8f: rpl_insn: eb 2f 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 8d 64 24 04 ff 74 24 0c c3 8d b4 26 00 00 00 00 e8 db ff ff ff
 SMP alternatives: c27fb587: final_insn: eb 2f 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 8d 64 24 04 ff 74 24 0c c3 8d b4 26 00 00 00 00 e8 db ff ff ff
 ------------[ cut here ]------------
 Not a NOP at 0xc27fb598
 WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:211 optimize_nops.isra.13+0x1a1/0x1c0
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-smp+ #3

Btw, Richard, why are you using a 32-bit kernel on 64-bit hardware?

Created attachment 297101 [details]
proposed patch

Richard, pls try this - it should fix it.

Thx.

Thanks Borislav,
 
    The patch works well on the x86_64 machine running in 32-bit mode.

    The x86_64 machine has 4 processors and ECC ram, much faster and safer than the average 32-bit machine.

    I found an x86 Intel Pentium 4 machine with the bug and the patch fixes it too.

    I have two more x86 AMD Athlon machines and I will test those to see if they have the bug...

(In reply to Richard Narron from comment #7)
>     The patch works well on the x86_64 machine running in 32-bit mode.

Thanks.

>     The x86_64 machine has 4 processors and ECC ram, much faster and safer
> than the average 32-bit machine.

And let me reiterate: you should run 64-bit kernels on 64-bit hardware. 64-bit kernels a orders of magnitude more tested than 32-bit kernels.

>     I found an x86 Intel Pentium 4 machine with the bug and the patch fixes
> it too.
>
>     I have two more x86 AMD Athlon machines and I will test those to see if
> they have the bug...

Ok, thanks for testing.

The two x86 AMD Athlon machines do not seem to have the bug and the patched version of the kernel runs fine.

Linux kernel 5.13-rc5 contains a fix from Borislav and it works.

The x86_64 machine running in x86 mode runs fine now and the Pentium 4 with the bug also runs fine now with 5.13-rc5.

Yap, upstream commit ID for future reference is:

2b31e8ed96b2 ("x86/alternative: Optimize single-byte NOPs at an arbitrary position")