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: <2785cae4-20be-85b5-7838-9a6dbd2baf72@rasmusvillemoes.dk>
References: <20210324020443.1815557-1-swboyd@chromium.org> <20210324020443.1815557-5-swboyd@chromium.org> <6dfb8ca2-20f3-e58a-ad6b-db6a6472afe0@rasmusvillemoes.dk> <161661308874.3012082.15483899786731677633@swboyd.mtv.corp.google.com> <2785cae4-20be-85b5-7838-9a6dbd2baf72@rasmusvillemoes.dk>
Subject: Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces
From:   Stephen Boyd <swboyd@chromium.org>
Cc:     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>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        linux-doc@vger.kernel.org, Matthew Wilcox <willy@infradead.org>
To:     Andrew Morton <akpm@linux-foundation.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Wed, 24 Mar 2021 15:28:43 -0700
Message-ID: <161662492346.3012082.17886011577458863951@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Precedence: bulk

Quoting Rasmus Villemoes (2021-03-24 15:21:34)
> On 24/03/2021 20.11, Stephen Boyd wrote:
> > Quoting Rasmus Villemoes (2021-03-24 02:57:13)
>=20
> >>
> >> Is there any reason you didn't just make b an optional flag that could
> >> be specified with or without R? I suppose the parsing is more difficult
> >> with several orthogonal flags (see escaped_string()), but it's a little
> >> easier to understand. Dunno, it's not like we're gonna think of 10 oth=
er
> >> things that could be printed for a symbol, so perhaps it's fine.
> >>
> >=20
> > I think I follow. So %pSb or %pSRb? If it's easier to understand then
> > sure. I was trying to avoid checking another character beyond fmt[1] but
> > it should be fine if fmt[1] is already 'R'.
> >=20
>=20
> I don't know. On the one hand, it seems sensible to allow such "flag"
> modifiers to appear independently and in any order. Because what if some
> day we think of some other property of the symbol we might want to
> provide access to via a "z" flag; when to allow all combinations of the
> R, b and z functionality we'd have to use four more random letters to
> stand for various combinations of those flags. On the other hand,
> vsprintf.c is already a complete wild west of odd conventions for
> %p<foo>, and it's not like symbol_string() gets extended every other
> release, and I can certainly understand the desire to keep the parsing
> of fmt minimal. So 'r' to mean 'Rb' is ok by me if you prefer that.

I'm inclined to use %pSb and %pSRb. The code looks to simpler and I
suppose we can worry about different ordering/combination problems if it
comes to it.

---8<---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 41ddc353ebb8..0e94cba5ba20 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -968,6 +968,8 @@ char *symbol_string(char *buf, char *end, void *ptr,
 #ifdef CONFIG_KALLSYMS
        if (*fmt =3D=3D 'B')
                sprint_backtrace(sym, value);
+       else if (*fmt =3D=3D 'S' && (fmt[1] =3D=3D 'b' || (fmt[1] =3D=3D 'R=
' && fmt[2] =3D=3D 'b')))
+               sprint_symbol_stacktrace(sym, value);
        else if (*fmt !=3D 's')
                sprint_symbol(sym, value);
        else