All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org,
	Lech Perczak <l.perczak@camlintechnologies.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Theodore Ts'o <tytso@mit.edu>,
	John Ogness <john.ogness@linutronix.de>
Subject: Re: [PATCHv2] printk: queue wake_up_klogd irq_work only if per-CPU areas are ready
Date: Thu, 5 Mar 2020 10:30:14 +0900	[thread overview]
Message-ID: <20200305013014.GA174444@google.com> (raw)
In-Reply-To: <20200304152159.2p7d7dnztf433i24@pathway.suse.cz>

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

  reply	other threads:[~2020-03-05  1:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 11:30 [PATCHv2] printk: queue wake_up_klogd irq_work only if per-CPU areas are ready Sergey Senozhatsky
2020-03-04 15:21 ` Petr Mladek
2020-03-05  1:30   ` Sergey Senozhatsky [this message]
2020-03-05 18:53     ` Greg Kroah-Hartman
2020-04-09 19:25       ` Simon Kirby
2020-04-10  3:07         ` Sergey Senozhatsky
2020-04-10 23:21           ` Sergey Senozhatsky
2020-04-01 19:34 ` Jann Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200305013014.GA174444@google.com \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=l.perczak@camlintechnologies.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.