linux-kernel - Re: Lockup of (raid5 or raid6) + vdo after taking out a disk under load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c396092e5c7698254a1ca7818f81178b5c1ee70d.camel@yandex.ru>
Date: Tue, 23 Jul 2024 17:34:24 +0300
From: Konstantin Kharlamov <Hi-Angel@...dex.ru>
To: Yu Kuai <yukuai1@...weicloud.com>, Song Liu <song@...nel.org>, 
 linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
 "yangerkun@...wei.com" <yangerkun@...wei.com>, "yukuai (C)"
 <yukuai3@...wei.com>
Subject: Re: Lockup of (raid5 or raid6) + vdo after taking out a disk under
 load

On Mon, 2024-07-22 at 20:56 +0300, Konstantin Kharlamov wrote:
> On Mon, 2024-07-15 at 09:56 +0800, Yu Kuai wrote:
> > Line number will be helpful.
> 
> So, after tinkering with building scripts I managed to build modules
> with debug symbols (not the kernel itself but should be good enough),
> but for some reason kernel doesn't show line numbers in stacktraces.
> No idea what could be causing it

FTR, getting a kernel with debug info doesn't seem to be on the
horizon. I tried researching into that and apparently kernel has
`bindeb-pkg` target that we're using to build the kernel, and it
unconditionally strips it (similarly to deb-pkg and srcdeb-pkg targets,
at scripts/Makefile.package:121). I found a few places in code where I
removed the stripping and replaced `strip` to `false` to make sure I
get an error if something else tries to do that, but at this point I'm
stuck with kernel succeeding the build, but leaving missing binaries
behind.

I might try digging into why installing `-dbg` package doesn't make
lines appear in stacktraces, but I presume it would take some time.

Meanwhile, as far as raid456 driver concerned, I can decode it manually
by feeding stacktrace offsets to gdb.