linux-kernel - Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces

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]

Date:   Wed, 24 Mar 2021 23:21:34 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Stephen Boyd <swboyd@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>
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

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.

Rasmus