lkml.org 
[lkml]   [2018]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers
    From
    Date
    On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
    > There are few printk formats that make sense only with two or more
    > specifiers. Also some specifiers make sense only when a kernel feature
    > is enabled.
    >
    > The handling of unknown specifiers is strange, inconsistent, and
    > even leaking the address. For example, netdev_bits() prints the
    > non-hashed pointer value or clock() prints "(null)".
    >
    > The best solution seems to be in flags_string(). It does not print any
    > misleading value. Instead it calls WARN_ONCE() describing the unknown
    > specifier. Therefore it clearly shows the problem and helps to find
    > it.
    >
    > Note that WARN_ONCE() used to cause recursive printk(). But it is safe
    > now because vscnprintf() is called in printk_safe context from
    > vprintk_emit().
    >

    > - if (!IS_ENABLED(CONFIG_HAVE_CLK) || !clk)
    > + if (!IS_ENABLED(CONFIG_HAVE_CLK)) {
    > + WARN_ONCE(1, "Unsupported pointer format specifier:
    > %%pC\n");
    > + return buf;
    > + }
    > +
    > + if (!clk)
    > return string(buf, end, NULL, spec);

    This change collides with my patch series. Can you elaborate what your
    thoughts are about my patches? Are you going incorporate them to your
    series? Should I send them independently?

    --
    Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Intel Finland Oy

    \
     
     \ /
      Last update: 2018-04-07 16:27    [W:4.331 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site