From: John Ogness <john.ogness@linutronix.de>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>, linux-kernel@vger.kernel.org
Subject: Re: Removal of printk safe buffers delays NMI context printk
Date: Thu, 04 Nov 2021 17:24:28 +0106 [thread overview]
Message-ID: <87ee7vki7f.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <1636039236.y415994wfa.astroid@bobo.none>
Hi Nick,
On 2021-11-05, Nicholas Piggin <npiggin@gmail.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
next prev parent reply other threads:[~2021-11-04 16:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 15:54 Removal of printk safe buffers delays NMI context printk Nicholas Piggin
2021-11-04 16:18 ` John Ogness [this message]
2021-11-05 1:26 ` Nicholas Piggin
2021-11-05 9:55 ` John Ogness
2021-11-05 11:43 ` Nicholas Piggin
2021-11-05 13:57 ` John Ogness
2021-11-05 16:23 ` Petr Mladek
2021-11-05 16:44 ` John Ogness
2021-11-06 0:26 ` Nicholas Piggin
2021-11-06 20:05 ` John Ogness
2021-11-05 23:57 ` Nicholas Piggin
2021-11-05 23:48 ` Nicholas Piggin
2021-11-05 16:01 ` Petr Mladek
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=87ee7vki7f.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=pmladek@suse.com \
/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.