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: <161662492346.3012082.17886011577458863951@swboyd.mtv.corp.google.com>
Date:   Wed, 24 Mar 2021 15:28:43 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Jessica Yu <jeyu@...nel.org>,
        Evan Green <evgreen@...omium.org>,
        Hsin-Yi Wang <hsinyi@...omium.org>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-doc@...r.kernel.org, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces

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)
> 
> >>
> >> 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 other
> >> things that could be printed for a symbol, so perhaps it's fine.
> >>
> > 
> > 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'.
> > 
> 
> 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 == 'B')
                sprint_backtrace(sym, value);
+       else if (*fmt == 'S' && (fmt[1] == 'b' || (fmt[1] == 'R' && fmt[2] == 'b')))
+               sprint_symbol_stacktrace(sym, value);
        else if (*fmt != 's')
                sprint_symbol(sym, value);
        else

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ