On Mon, Jan 27, 2025 at 11:12:11AM -0800, Linus Torvalds wrote: > On Mon, 27 Jan 2025 at 09:19, Sasha Levin <sashal@xxxxxxxxxx> wrote: > > With this pulled on top of Linus's tree, LKFT is managing to trigger > > kfence warnings: > > <3>[ 62.180289] BUG: KFENCE: out-of-bounds read in d_same_name+0x4c/0xd0 > > <3>[ 62.180289] > > <3>[ 62.182647] Out-of-bounds read at 0x00000000eedd4b55 (64B right of kfence-#174): > > <4>[ 62.184178] d_same_name+0x4c/0xd0 > Bah. I've said this before, but I really wish LKFT would use debug > builds and run the warnings through scripts/decode_stacktrace.sh. > Getting filenames and line numbers (and inlining information!) for > stack traces can be really really useful. > I think you are using KernelCI builds (at least that was the case last > time), and apparently they are non-debug builds. And that's possibly > due to just resource issues (the debug info does take a lot more disk > space and makes link times much longer too). So it might not be easily > fixable. They're not, they're using their own builds done with their tuxsuite service which is a cloud front end for their tuxmake tool, that does have the ability to save the vmlinux. Poking around the LKFT output it does look like they're doing that for the LKFT builds: https://qa-reports.linaro.org/lkft/sashal-linus-next/build/v6.13-rc7-8584-gd4639f3659ae/testrun/27027254/suite/build/test/gcc-13-tinyconfig/details/ https://storage.tuxsuite.com/public/linaro/lkft/builds/2sDW1jDhjHPNl1XNezFhsjSlvpI/ so hopefully the information is all there and it's just a question of people doing the decode when reporting issues from LKFT. > But let's see if it might be an option to get this capability. So I'm > adding the kernelci list to see if somebody goes "Oh, that was just an > oversight" and might easily be made to happen. Fingers crossed. The issue with KernelCI has been that it's not storing the vmlinux, this was indeed done due to space issues like you suggest. With the new infrastructure that's been rolled out as part of the KernelCI 2.0 revamp the storage should be a lot more scaleable and so this should hopefully be a cost issue rather than actual space limits like it used to be so more tractable. AFAICT we haven't actually revisited making the required changes to include the vmlinux in the stored output though, I filed a ticket: https://github.com/kernelci/kernelci-project/issues/509 The builds themselves are generally using standard defconfigs and derivatives of that so will normally have enough debug info for decode_stacktrace.sh. Where they don't we should probably just change that upstream.
Attachment:
signature.asc
Description: PGP signature
