Reported internally by google production kernel team. Commenting some of the discussion here.
It seems that kexec is broken; internal teams found that definitions in arch/x86/purgatory/string.c lead to infinite recursion.
Fixes are being discussed internally.
CrOS issue: https://bugs.chromium.org/p/chromium/issues/detail?id=984056
I wonder if we can detect more bugs like this one with LTP.
Following the discussion CrOS #984056.
Looking at:
[ arch/x86/purgatory/Makefile ]
KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -Os -mcmodel=large
Instead of using -Os optimization use -O2?
Does that help?
@tpimh
Concerning LTP - are there specific testcases to check kexec?
You happen to know the testcase-name(s)?
./runltp -p -l <log file name> -f <testcase name>
It's a while I used LTP.
UPDATE: Add mini-howto
[1] https://github.com/linux-test-project/ltp/blob/master/doc/mini-howto-building-ltp-from-git.txt
I don't know specifically about kexec, but found kdump test automation suite.
Instead of using -Os optimization use -O2?
Does that help?
Clang generates the references to memcmp/memset unconditionally. We're testing a patch internally that reuses definitions from arch/x86/boot/compressed/string.c.
Submitted: https://lkml.org/lkml/2019/7/18/805
I've sent backports to 4.19 FWIW. Also, this was the last major issue before Google's COS kernel team could switch to clang built kernels. Now Google Cloud VM instances use clang built kernels. :zambia: :zap:
Most helpful comment
Patch accepted: https://git.kernel.org/tip/b059f801a937d164e03b33c1848bb3dca67c0b04