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]
Date:   Mon, 15 Feb 2021 06:55:02 +0100
From:   Thorsten Leemhuis <>
To:     Qais Yousef <>
Cc:     Jonathan Corbet <>,
        Randy Dunlap <>,,,
        Sasha Levin <>,
        Vlastimil Babka <>,
        Joerg Roedel <>,
        Damian Tometzki <>
Subject: Re: [PATCH] docs: reporting-issues.rst: explain how to decode stack

Hi! Many thx for looking into this, much appreciated!

Am 14.02.21 um 17:00 schrieb Qais Yousef:
> On 02/10/21 06:48, Thorsten Leemhuis wrote:
>> - * If the failure includes a stack dump, like an Oops does, consider decoding
>> -   it to find the offending line of code.
>> + * If your failure involves a 'panic', 'oops', or 'warning', consider decoding
> or 'BUG'? There are similar other places below that could benefit from this
> addition too.

Good point. In fact there are other places in the document where this is
needed as well. Will address those in another patch.

>> +   the kernel log to find the line of code that trigger the error.
>>   * If your problem is a regression, try to narrow down when the issue was
>>     introduced as much as possible.
>> @@ -869,6 +869,15 @@ pick up the configuration of your current kernel and then tries to adjust it
>>  somewhat for your system. That does not make the resulting kernel any better,
>>  but quicker to compile.
>> +Note: If you are dealing with a kernel panic, oops, or warning, please make
>> +sure to enable CONFIG_KALLSYMS when configuring your kernel. Additionally,
> s/make sure/try/

I did that, but ignored...

> s/kernel./kernel if you can./

...this. Yes, you have a point with...

> Less demanding wording in case the user doesn't have the capability to rebuild
> or deploy such a kernel where the problem happens. Maybe you can tweak it more
> if you like too :-)

...that, but that section in the document is about building your own
kernel, so I'd say we don't have to be that careful here.

>> +enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO, too; the latter is the
>> +relevant one of those two, but can only be reached if you enable the former. Be
>> +aware CONFIG_DEBUG_INFO increases the storage space required to build a kernel
>> +by quite a bit. But that's worth it, as these options will allow you later to
>> +pinpoint the exact line of code that triggers your issue. The section 'Decode
>> +failure messages' below explains this in more detail.
> I think worth mentioning too that the user should keep a log of the problem
> when first encountered and then attempt the above. Just in case the problem is
> not reproducible easily so the info is not lost.
> Maybe something like below:
> '''
> Always keep a record of the issue encountered in case it is hard to reproduce.
> Sending undecoded report is better than not sending a report at all.
> '''

Very good point, added.

>> +your kernel. If you did so, consider to decode the information from the
>> +kernel's log. That will make it a lot easier to understand what lead to the
>> +'panic', 'oops', or 'warning', which increases the chances enormously that
>> +someone can provide a fix.
> I suggest removing the word enormously. It helps, but it all depends on the
> particular circumstances. Sometimes it does, others it doesn't.


> This looks good to me in general. With the above minor nits fixed, feel free to
> add my
> Reviewed-by: Qais Yousef <>

Great, thx, will do!

Ciao, Thorsten

Powered by blists - more mailing lists