[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ee7vki7f.fsf@jogness.linutronix.de>
Date: Thu, 04 Nov 2021 17:24:28 +0106
From: John Ogness <john.ogness@...utronix.de>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Petr Mladek <pmladek@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: Removal of printk safe buffers delays NMI context printk
Hi Nick,
On 2021-11-05, Nicholas Piggin <npiggin@...il.com> wrote:
> It seems printk from NMI context is now delayed indefinitely and
> there is no printk_safe_flush equivalent (or I can't see one) to
> allow a NMI buffer to be flushed by a different CPU.
NMI flushing is triggered using irq work (for the same CPU). This should
not have changed recently. Are you reporting a new issue?
> This causes hard lockup watchdog messages to not get shown on the
> console. I can call printk from a different CPU and that seems to
> flush the stuck CPU's NMI buffer immediately.
Perhaps we should be triggering the irq work on multiple CPUs if from
NMI context?
> What's the best way to expose this? Can we have something like tihs?
>
> void printk_flush(void)
> {
> preempt_disable();
> if (console_trylock_spinning())
> console_unlock();
> preempt_enable();
> wake_up_klogd();
> }
We are planning on implementing a pr_flush() that will do something
similar. But I am wondering how you are planning on triggering a CPU to
call that function.
John Ogness
Powered by blists - more mailing lists