Re: [git pull] d_revalidate pile
Sasha Levin <[email protected]> Mon, 27 Jan 2025 17:32:18 -0500
| Newsgroups | dev.linux.lists.kernelci,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <Z5gJcnAPTXMoKwEr@lappy> |
[ Adding in the LKFT folks ] On Mon, Jan 27, 2025 at 08:38:50PM +0000, Mark Brown wrote: >On Mon, Jan 27, 2025 at 11:12:11AM -0800, Linus Torvalds wrote: >> On Mon, 27 Jan 2025 at 09:19, Sasha Levin <[email protected]> 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. My understanding was that becuase CONFIG_DEBUG_INFO_NONE=y is set, we actually don't have enough info to resolve line numbers. I've tried running decode_stacktrace.sh on the vmlinux image linked above, and indeed we can't get line numbers. -- Thanks, Sasha