On Thu, Mar 28, 2024 at 03:36:28PM +0800, kernel test robot wrote: > compiler: clang-17 > test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G > > (please refer to attached dmesg/kmsg for entire log/backtrace) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <oliver.sang@xxxxxxxxx> > | Closes: https://lore.kernel.org/oe-lkp/202403281553.79f5a16f-lkp@xxxxxxxxx > > > [ 25.175767][ T670] VFS: Warning: trinity-c2 using old stat() call. Recompile your binary. > [ 25.245597][ T669] general protection fault: 0000 [#1] PREEMPT SMP > [ 25.246417][ T669] CPU: 1 PID: 669 Comm: trinity-c1 Not tainted 6.8.0-rc5-00004-g6613d82e617d #1 85a4928d2e6b42899c3861e57e26bdc646c4c5f9 > [ 25.247743][ T669] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > [ 25.248865][ T669] EIP: restore_all_switch_stack (kbuild/src/consumer/arch/x86/entry/entry_32.S:957) > [ 25.249510][ T669] Code: 4c 24 10 36 89 48 fc 8b 4c 24 0c 81 e1 ff ff 00 00 36 89 48 f8 8b 4c 24 08 36 89 48 f4 8b 4c 24 04 36 89 48 f0 59 8d 60 f0 58 <0f> 00 2d 00 94 d5 c1 cf 6a 00 68 88 6b d4 c1 eb 00 fc 0f a0 50 b8 > All code > ======== > 0: 4c 24 10 rex.WR and $0x10,%al > 3: 36 89 48 fc ss mov %ecx,-0x4(%rax) > 7: 8b 4c 24 0c mov 0xc(%rsp),%ecx > b: 81 e1 ff ff 00 00 and $0xffff,%ecx > 11: 36 89 48 f8 ss mov %ecx,-0x8(%rax) > 15: 8b 4c 24 08 mov 0x8(%rsp),%ecx > 19: 36 89 48 f4 ss mov %ecx,-0xc(%rax) > 1d: 8b 4c 24 04 mov 0x4(%rsp),%ecx > 21: 36 89 48 f0 ss mov %ecx,-0x10(%rax) > 25: 59 pop %rcx > 26: 8d 60 f0 lea -0x10(%rax),%esp > 29: 58 pop %rax > 2a:* 0f 00 2d 00 94 d5 c1 verw -0x3e2a6c00(%rip) # 0xffffffffc1d59431 <-- trapping instruction This is due to 64-bit addressing with CONFIG_X86_32=y on clang. I haven't tried with clang, but I don't see this happening with gcc-11: entry_INT80_32: ... <+446>: mov 0x4(%esp),%ecx <+450>: mov %ecx,%ss:-0x10(%eax) <+454>: pop %ecx <+455>: lea -0x10(%eax),%esp <+458>: pop %eax <+459>: verw 0xc1d5c700 <---------- <+466>: iret > 31: cf iret > 32: 6a 00 push $0x0 > 34: 68 88 6b d4 c1 push $0xffffffffc1d46b88 > 39: eb 00 jmp 0x3b ... The config has CONFIG_X86_32=y, but it is possible that in 32-bit build with clang, 64-bit mode expansion of "VERW (_ASM_RIP(addr))" is getting used i.e. __ASM_FORM_RAW(b) below: file: arch/x86/include/asm/asm.h ... #ifndef __x86_64__ /* 32 bit */ # define __ASM_SEL(a,b) __ASM_FORM(a) # define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(a) #else /* 64 bit */ # define __ASM_SEL(a,b) __ASM_FORM(b) # define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(b) <-------- #endif ... /* Adds a (%rip) suffix on 64 bits only; for immediate memory references */ #define _ASM_RIP(x) __ASM_SEL_RAW(x, x (__ASM_REGPFX rip)) Possibly __x86_64__ is being defined with clang even when CONFIG_X86_32=y. I am not sure about current level of 32-bit mode support in clang. This seems inconclusive: https://discourse.llvm.org/t/x86-32-bit-testing/65480 Does anyone care about 32-bit mode builds with clang?
