linux-kernel - Re: Linux 5.8-rc1 BUG unable to handle page fault (snd

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: <CAHk-=wgB6xs-gfihkMSngyAcRHaQ0oE3jVawVMzzAh4Xm0VsSQ@mail.gmail.com>
Date:   Mon, 15 Jun 2020 13:55:50 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Shuah Khan <skhan@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>,
        Konstantin Khlebnikov <koct9i@...il.com>
Cc:     Joerg Roedel <jroedel@...e.de>, Andy Lutomirski <luto@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Takashi Iwai <tiwai@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm)

On Mon, Jun 15, 2020 at 1:41 PM Shuah Khan <skhan@...uxfoundation.org> wrote:
>
> I have CONFIG_DEBUG_INFO enabled. Ran the stack trace through
> scripts/decode_stacktrace.sh

Thanks. It looks like it isn't needed and people already know what the cause is.

Also, sadly the stack trace decoding didn't end up as useful as it
could have been because it looks like it doesn't know how to do the
nice address lookups for modules.

So this:

> [   15.341237] RIP: 0010:__memset (arch/x86/lib/memset_64.S:41)

gets nicely pinpointed to the source, but the most critical part of
the call trace is in modules, and there we end up having just

> [   15.341259] Call Trace:
> [   15.341267] ? snd_pcm_hw_params+0x3ca/0x440 snd_pcm
> [   15.341272] snd_pcm_common_ioctl+0x173/0xf20 snd_pcm
> [   15.341277] ? snd_ctl_ioctl+0x1c5/0x710 snd
> [   15.341282] snd_pcm_ioctl+0x27/0x40 snd_pcm

without then looking at the debug info in the snd_pcm module to figure that out.

Then when the call trace gets back to non-module code, it looks good again:

> [   15.341285] ksys_ioctl (fs/ioctl.c:49 /home/shuah/lkml/linux_5.8/fs/ioctl.c:753)
> [   15.341288] __x64_sys_ioctl (fs/ioctl.c:760)
> [   15.341291] do_syscall_64 (arch/x86/entry/common.c:359)
> [   15.341294] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:124)

with pinpointing to exactly where the calls are.

I note that Konstantin Khlebnikov did add support to do the module
parts too back in 2016, but it requires people to know to give the
module path too.

Adding him and Sasha to the participants in case there are ideas on
how to improve on this (and party just because I want to once again
give scripts/decode_stacktrace.sh soem more mention, because a lot of
people seem to be unaware of how useful it can be to make oopses and
traces more readable..

Maybe even just a warning about lacking a module path when there are
module symbols present?

             Linus