lkml.org 
[lkml]   [2020]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv2] printk: queue wake_up_klogd irq_work only if per-CPU areas are ready
    On (20/03/04 16:21), Petr Mladek wrote:
    [..]
    > > Fix printk_deferred() and do not queue per-CPU irq_work
    > > before per-CPU areas are initialized.
    > >
    > > [0] https://lore.kernel.org/lkml/aa0732c6-5c4e-8a8b-a1c1-75ebe3dca05b@camlintechnologies.com/
    > >
    > > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    > > Reported-by: Lech Perczak <l.perczak@camlintechnologies.com>
    > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    > > Cc: Theodore Ts'o <tytso@mit.edu>
    > > Cc: John Ogness <john.ogness@linutronix.de>
    >
    > Reviewed-by: Petr Mladek <pmladek@suse.com>

    Thanks!

    > Now, the question is whether to hurry this fix into 5.6 or if
    > it could wait for 5.7.
    >
    > I think that it could wait because 5.6 is not affected by
    > the particular printk_deferred(). This patch fixes a long-term
    > generic problem. But I am open for other opinions.

    Good question. My 5 cents, I would _probably_ push it now. Not
    because it fixes any known issues on 5.6, but because we have
    a number of LTS kernel (4.19, 4.14, 4.9, 4.4, 3.16) that can be
    affected should 1b710b1b10eff9d4 be backported to those kernels.
    Which is quite likely, I suspect. The sooner we fix printk_deferred(),
    the sooner -stable/LTS picks up the fix, so that we don't have same
    regression reports in the future. The regression in question is
    pretty hard to track down, git-bisect, perhaps, is the only reasonably
    fast way.

    -ss

    \
     
     \ /
      Last update: 2020-03-05 02:30    [W:3.106 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site