Re: [x86/mm/64] f154f29085: BUG:kernel_reboot-without-warning_in_boot_stage

[Borislav Petkov <bp@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

On Thu, Dec 16, 2021 at 03:04:16PM +0800, Yin Fengwei wrote:
> The testing was with Qemu.

This is hardly what I asked for.

> And we found that the hang is related with clang-14.

I saw that already.

> The original report showed the kernel is built with clang-14:
>         # build kernel
> 	cd linux
> 	cp config-5.16.0-rc3-00003-gf154f290855b .config
> 	make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
> 	make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install

I saw that too.

> Looks like KASAN related stub generated by clang-14 (KASAN_SHADOW_OFFSET and asan_report).
> This function is early function called before kasan_init.
> 
> Looks like we need to disable KASAN_SANITIZE for arch/x86/kernel/cpu/common.c. So clang-14 will
> be happy with this kind of early TLB flush? Thanks.

Ok, I don't understand: I asked for how exactly to reproduce and whether
you can send me your vmlinux you built with your clang-14. What I get is
some possible explanation about what might be happening.

So what do you expect me to do? Say, "oh, sure, you're right, send me a
patch" without even being able to see for myself what the root cause is?

What if it is not the kernel's fault but clang-14 is miscompiling crap
as in so many other cases?

I built clang-14 and built with your .config and it works here fine. So
why does yours fail?

Or what's the point of all this?

I mean, if you cannot send me what I ask for, you can say so. Then I can
ignore this whole report altogether and waste my time somewhere else.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg