Linux Documentation
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Petr Mladek <pmladek@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>, Jessica Yu <jeyu@kernel.org>,
	Evan Green <evgreen@chromium.org>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 5/7] printk: Make %pS and friends print module build ID
Date: Wed, 3 Mar 2021 20:19:32 -0500	[thread overview]
Message-ID: <20210303201932.7ac93f12@oasis.local.home> (raw)
In-Reply-To: <161481830876.1478170.4374239517736205573@swboyd.mtv.corp.google.com>

On Wed, 03 Mar 2021 16:38:28 -0800
Stephen Boyd <swboyd@chromium.org> wrote:

> I'm starting to feel like nobody read the commit text, or I messed up
> somehow and the commit text was confusing? :(
> 

I read it, I'm just unfamiliar with it. I don't use pstore, and I'm not
sure what "crashdump" is. Do you mean the kexec/kdump? in which case
you can retrieve data within the kernel quite easily.

I haven't used debuginfod (never heard of it before actually).

> │ This is especially helpful for crash debugging with pstore or crashdump                                                                                                                                         
> │ kernels. If we have the build ID for the module in the stacktrace we can                                                                                                                                        
> │ request the debug symbols for the module from a remote debuginfod server                                                                                                                                        
> │ or parse stacktraces at a later time with decode_stacktrace.sh by                                                                                                                                               
> │ downloading the correct symbols based on the build ID. This cuts down on                                                                                                                                        
> │ the amount of time and effort needed to find the correct kernel modules                                                                                                                                         
> │ for a stacktrace by encoding that information into it.  

Are you saying it's common to have modules from different builds?

> 
> In some distro (read: non-kernel dev) workflows the vmlinux isn't
> shipped on the device and crash handling is done offline or much later.
> Using the build ID[1] is a common way to identify the binary that's
> running on the device. In conjunction with a debuginfod[2] server you
> can download the symbols for a crash automatically if you have the build
> ID information.
> 
> I can add a patch that updates decode_stacktrace.sh to show how it can
> download the correct vmlinux/modules if it isn't provided on the
> commandline.

Are you just trying to match modules with the builds that they were
created with?

> 
> If the debug symbols are on some public server then in theory we could
> have some robot sitting on the mailing list that looks for stacktraces
> and automatically replies with information about the line number/file
> and even provides the code snippet for the code that's crashing from
> that binary, because it's all stored in the full debuginfo builds.

Again, I have no idea how buildids are created or what they are used
for. This is the first time I've even heard about them. I'm all for
helping other people out to make their workflow easier, if it doesn't
make a mess for everyone else.

-- Steve


  reply	other threads:[~2021-03-04  1:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01 17:47 [PATCH 0/7] Add build ID to stacktraces Stephen Boyd
2021-03-01 17:47 ` [PATCH 5/7] printk: Make %pS and friends print module build ID Stephen Boyd
2021-03-02  2:43   ` Steven Rostedt
2021-03-02 23:24     ` Stephen Boyd
2021-03-04 17:19     ` Matthew Wilcox
2021-03-04 19:11       ` Stephen Boyd
2021-03-03  2:01   ` Steven Rostedt
2021-03-03  3:00     ` Stephen Boyd
2021-03-03  8:19       ` Andy Shevchenko
2021-03-03  8:56         ` Stephen Boyd
2021-03-03 10:25   ` Petr Mladek
2021-03-03 15:00     ` Steven Rostedt
2021-03-03 16:17       ` Andy Shevchenko
2021-03-04  0:38         ` Stephen Boyd
2021-03-04  1:19           ` Steven Rostedt [this message]
2021-03-04  6:25             ` Stephen Boyd
2021-03-04  1:17     ` Stephen Boyd
2021-03-04 17:00   ` Matthew Wilcox
2021-03-04 19:15     ` Stephen Boyd
2021-03-04 23:11       ` Rasmus Villemoes
2021-03-05  4:21         ` Stephen Boyd

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=20210303201932.7ac93f12@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ast@kernel.org \
    --cc=evgreen@chromium.org \
    --cc=hsinyi@chromium.org \
    --cc=jeyu@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pmladek@suse.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=swboyd@chromium.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