[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220923113107.79d3e013@gandalf.local.home>
Date: Fri, 23 Sep 2022 11:31:07 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: John Ogness <john.ogness@...utronix.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Linus Torvalds <torvalds@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Daniel Vetter <daniel@...ll.ch>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Helge Deller <deller@....de>,
Jason Wessel <jason.wessel@...driver.com>,
Daniel Thompson <daniel.thompson@...aro.org>,
John Kacur <jkacur@...hat.com>,
"John B. Wyatt IV" <jbwyatt4@...il.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: printk meeting at LPC 2022
On Fri, 23 Sep 2022 16:55:28 +0206
John Ogness <john.ogness@...utronix.de> wrote:
> All other consoles could then be tried as a "last hope" at the very
> end of panic(), after all records have been flushed to reliable
> consoles and when it no longer matters if a console kills the CPU. For
> non-panic emergencies (warn, rcu stalls, etc), there may be other
> flags that would be needed.
I think we may need to check if kexec is involved. We don't want one of
these "last hope" consoles to lock up the system preventing kexec to occur.
But if there's no kexec, and the system is just going to lock up anyway,
then sure go ahead and call the unsafe consoles.
-- Steve
Powered by blists - more mailing lists