On Fri, Dec 01, 2023 at 10:35:33AM +0100, Francis Laniel wrote:
Hi!
Le vendredi 1 décembre 2023, 09:21:33 CET Greg Kroah-Hartman a écrit :
On Thu, Nov 30, 2023 at 12:11:31PM -0600, Daniel Díaz wrote:
Hello!
On Thu, 30 Nov 2023 at 11:44, Guenter Roeck linux@roeck-us.net wrote:
On 11/30/23 09:21, Daniel Díaz wrote:
Hello!
Lots of failures everywhere:
- clang-17-lkftconfig arm64
- clang-17-lkftconfig arm64
- clang-17-lkftconfig arm64
- clang-lkftconfig arm64
- clang-lkftconfig arm
- clang-lkftconfig i386
- clang-lkftconfig x86_64
- gcc-12-lkftconfig arm64
- gcc-12-lkftconfig arm
- gcc-12-lkftconfig i386
- gcc-12-lkftconfig x86_64
- gcc-12-lkftconfig-64k_page_size arm64
- gcc-12-lkftconfig-64k_page_size arm64
- gcc-12-lkftconfig-armv8_features arm64
- gcc-12-lkftconfig-debug arm64
- gcc-12-lkftconfig-debug arm64
- gcc-12-lkftconfig-debug arm
- gcc-12-lkftconfig-debug i386
- gcc-12-lkftconfig-debug x86_64
- gcc-12-lkftconfig-debug-kmemleak arm64
- gcc-12-lkftconfig-debug-kmemleak arm
- gcc-12-lkftconfig-debug-kmemleak i386
- gcc-12-lkftconfig-debug-kmemleak x86_64
- gcc-12-lkftconfig-devicetree arm64
- gcc-12-lkftconfig-kasan arm64
- gcc-12-lkftconfig-kasan arm64
- gcc-12-lkftconfig-kasan x86_64
- gcc-12-lkftconfig-kselftest arm64
- gcc-12-lkftconfig-kselftest-kernel arm64
- gcc-12-lkftconfig-kselftest-kernel arm
- gcc-12-lkftconfig-kselftest-kernel i386
- gcc-12-lkftconfig-kunit arm64
- gcc-12-lkftconfig-kunit arm64
- gcc-12-lkftconfig-kunit arm
- gcc-12-lkftconfig-kunit i386
- gcc-12-lkftconfig-kunit x86_64
- gcc-12-lkftconfig-libgpiod arm64
- gcc-12-lkftconfig-libgpiod arm
- gcc-12-lkftconfig-libgpiod i386
- gcc-12-lkftconfig-libgpiod x86_64
- gcc-12-lkftconfig-perf arm64
- gcc-12-lkftconfig-perf-kernel arm64
- gcc-12-lkftconfig-perf-kernel arm
- gcc-12-lkftconfig-perf-kernel i386
- gcc-12-lkftconfig-perf-kernel x86_64
- gcc-12-lkftconfig-rcutorture arm64
- gcc-12-lkftconfig-rcutorture arm64
- gcc-12-lkftconfig-rcutorture arm
- gcc-12-lkftconfig-rcutorture i386
- gcc-12-lkftconfig-rcutorture x86_64
It's essentially this:
-----8<-----
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=x86_64 SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu- 'CC=sccache x86_64-linux-gnu-gcc' 'HOSTCC=sccache gcc'
arch/x86/kernel/smp.o: warning: objtool: sysvec_reboot()+0x51: unreachable instruction
x86_64-linux-gnu-ld: kernel/trace/trace_kprobe.o: in function
`__trace_kprobe_create': trace_kprobe.c:(.text+0x2f39): undefined reference to
`kallsyms_on_each_symbol'
x86_64-linux-gnu-ld: kernel/trace/trace_kprobe.o: in function
`create_local_trace_kprobe': trace_kprobe.c:(.text+0x384b): undefined reference to
`kallsyms_on_each_symbol'
make[1]: *** [/builds/linux/Makefile:1227: vmlinux] Error 1 make[1]: Target '__all' not remade because of errors. make: *** [Makefile:226: __sub-make] Error 2 make: Target '__all' not remade because of errors.
----->8-----
It only affects 5.15. Bisection in progress.
I guess it will point to
Francis Laniel flaniel@linux.microsoft.com
tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbolsIt sure did!: commit 7b4375c36a4c0e1b4b97ccbcdd427db5a460e04f Author: Francis Laniel flaniel@linux.microsoft.com Date: Fri Oct 20 13:42:49 2023 +0300 tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols commit b022f0c7e404887a7c5229788fc99eff9f9a80d5 upstream.
Reverting that commit made the build pass again.
{sigh}
Francis, I think this is the second or third time this has happened with the attempt to get this patch merged. I'm going to go drop it from all of the pending stable queues again, and please, if you wish to have it applied in the future, I am going to have to see some proof it was actually tested on the architectures that it keeps breaking.
Sorry for the disagreement, for this one, I had to add the CONFIG_LIVEPATCH to then be able to call kallsyms_on_each_symbol(), as on 5.15, this function is within a ifdef guard [1].
I suppose you do not want to add CONFIG_LIVEPATCH to default config, so I will try to find a way for this specific kernel!
It doesn't matter about any "default config", you can not break the build of any config.
Did you get problems only for 5.15 kernel? Or others too?
I don't know, but for obvious reasons if it is not working in 5.15.y, we can't take it in older kernels as that would be a regression when people move to a newer one.
In the second case, can you please link me the problems and I will polish everything.
Please take some time with a cross-compiler on the above listed architectures and configurations to verify your changes do not break anything again.
thanks,
greg k-h