[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <84qzvueq4w.fsf@jogness.linutronix.de>
Date: Thu, 25 Sep 2025 13:25:11 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby
<jirislaby@...nel.org>, Sergey Senozhatsky <senozhatsky@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>, Thomas Gleixner
<tglx@...utronix.de>, Esben Haabendal <esben@...nix.com>,
linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, Andy
Shevchenko <andriy.shevchenko@...ux.intel.com>, Arnd Bergmann
<arnd@...db.de>, Tony Lindgren <tony@...mide.com>, Niklas Schnelle
<schnelle@...ux.ibm.com>, Serge Semin <fancer.lancer@...il.com>, Andrew
Murray <amurray@...goodpenguin.co.uk>
Subject: Re: [RFC 0/1] serial: 8250: nbcon_atomic_flush_pending() might
trigger watchdog warnigns
On 2025-09-25, John Ogness <john.ogness@...utronix.de> wrote:
>> I am going to try implementing the 3rd solution and see how
>> complicated it would be.
>>
>> It would be possible to change it two 2nd easily just by
>> using a global counter and updating it in emergency_enter/exit API.
>
> Basically you are talking about changing the per-CPU emergency counter
> to be global.
Sorry, I spoke too quickly there. The per-CPU emergency counter is still
necessary to make sure the CPU with the emergency is the one that is
pushing out the messages, i.e. printk() is only expensive for the CPU
dealing with an emergency.
John
Powered by blists - more mailing lists