linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Sasha Levin <sashal@kernel.org>,
	Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Joerg Roedel <jroedel@suse.de>, Andy Lutomirski <luto@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Takashi Iwai <tiwai@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	skhan@linuxfoundation.org
Subject: Re: Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm)
Date: Mon, 15 Jun 2020 15:18:54 -0600	[thread overview]
Message-ID: <c35745bb-5700-f6c8-ae5b-e931502cb270@linuxfoundation.org> (raw)
In-Reply-To: <CAHk-=wgB6xs-gfihkMSngyAcRHaQ0oE3jVawVMzzAh4Xm0VsSQ@mail.gmail.com>

On 6/15/20 2:55 PM, Linus Torvalds wrote:
> On Mon, Jun 15, 2020 at 1:41 PM Shuah Khan <skhan@linuxfoundation.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..
> 

Thanks. I usually decode all of this by hand. This script saves a lot
of time. Very cool.

Yeah. I should have thought about adding module path. With module path
added, I get better results:

[   15.341267] ? snd_pcm_hw_params (./include/linux/string.h:391 
/home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:759) snd_pcm
[   15.341272] snd_pcm_common_ioctl (sound/core/pcm_native.c:792 
/home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:3210) snd_pcm
[   15.341277] ? snd_ctl_ioctl+0x1c5/0x710 snd
[   15.341282] snd_pcm_ioctl (sound/core/pcm_native.c:3297) snd_pcm
[   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)
[   15.341296] RIP: 0033:0x7fcbaf56137b
[ 15.341297] Code: Bad RIP value.

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

It does tell you the usage.

Usage:
	scripts/decode_stacktrace.sh [vmlinux] [base path] [modulespath]


I would be useful to add a warning.

thanks,
-- Shuah

  reply	other threads:[~2020-06-15 21:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-15 18:48 Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm) Shuah Khan
2020-06-15 19:47 ` David Rientjes
2020-06-15 19:48 ` Linus Torvalds
2020-06-15 20:41   ` Shuah Khan
2020-06-15 20:55     ` Linus Torvalds
2020-06-15 21:18       ` Shuah Khan [this message]
2020-06-15 22:23         ` Linus Torvalds
2020-06-15 22:24       ` [PATCH] scripts/decode_stacktrace: warn when modpath is needed but is unset Sasha Levin
2020-06-15 22:37         ` Linus Torvalds
2020-06-15 22:43           ` Linus Torvalds
2020-06-15 23:24             ` Sasha Levin
2020-06-15 19:57 ` Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm) Takashi Iwai
2020-06-15 20:53   ` Shuah Khan
2020-06-15 21:04     ` Shuah Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c35745bb-5700-f6c8-ae5b-e931502cb270@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=jroedel@suse.de \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sashal@kernel.org \
    --cc=tiwai@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).