Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <YG3J03GY+QqtKMlu@alley>
References: <20210331030520.3816265-1-swboyd@chromium.org> <20210331030520.3816265-5-swboyd@chromium.org> <YG3J03GY+QqtKMlu@alley>
Subject: Re: [PATCH v3 04/12] module: Add printk format to add module build ID to stacktraces
From:   Stephen Boyd <swboyd@chromium.org>
Cc:     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>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        linux-doc@vger.kernel.org, Matthew Wilcox <willy@infradead.org>
To:     Petr Mladek <pmladek@suse.com>
Date:   Wed, 07 Apr 2021 23:58:47 -0700
Message-ID: <161786512790.3790633.16827318365663068135@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Precedence: bulk

Quoting Petr Mladek (2021-04-07 08:03:47)
> On Tue 2021-03-30 20:05:12, Stephen Boyd wrote:
> > Let's make kernel stacktraces easier to identify by including the build
> > ID[1] of a module if the stacktrace is printing a symbol from a module.
> > This makes it simpler for developers to locate a kernel module's full
> > debuginfo for a particular stacktrace. Combined with
> > scripts/decode_stracktrace.sh, a developer can download the matching
> > debuginfo from a debuginfod[2] server and find the exact file and line
> > number for the functions plus offsets in a stacktrace that match the
> > module. This is especially useful for pstore crash debugging where the
> > kernel crashes are recorded in something like console-ramoops and the
> > recovery kernel/modules are different or the debuginfo doesn't exist on
> > the device due to space concerns (the debuginfo can be too large for
> > space limited devices).
> >=20
> > @@ -359,15 +369,17 @@ int lookup_symbol_attrs(unsigned long addr, unsig=
ned long *size,
> > =20
> >  /* Look up a kernel symbol and return it in a text buffer. */
> >  static int __sprint_symbol(char *buffer, unsigned long address,
> > -                        int symbol_offset, int add_offset)
> > +                        int symbol_offset, int add_offset, int add_bui=
ldid)
> >  {
> >       char *modname;
> > +     const unsigned char *buildid;
> >       const char *name;
> >       unsigned long offset, size;
> >       int len;
> > =20
> >       address +=3D symbol_offset;
> > -     name =3D kallsyms_lookup(address, &size, &offset, &modname, buffe=
r);
> > +     name =3D kallsyms_lookup_buildid(address, &size, &offset, &modnam=
e, &buildid,
> > +                                    buffer);
> >       if (!name)
> >               return sprintf(buffer, "0x%lx", address - symbol_offset);
> > =20
> > @@ -379,8 +391,12 @@ static int __sprint_symbol(char *buffer, unsigned =
long address,
> >       if (add_offset)
> >               len +=3D sprintf(buffer + len, "+%#lx/%#lx", offset, size=
);
>=20
> Please add something like:
>=20
>         /* Keep BUILD_ID_SIZE_MAX in sync with the below used %20phN */
>         BUILD_BUG_ON(BUILD_ID_SIZE_MAX !=3D 20)
>=20

Done. Hopefully the "GNU" string check also fixes this module problem
you're seeing.