From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region
Date: Fri, 27 May 2016 16:56:01 +0200 [thread overview]
Message-ID: <20160527145601.GC24120@linutronix.de> (raw)
In-Reply-To: <20160527101251.0ae36e23@gandalf.local.home>
* Steven Rostedt | 2016-05-27 10:12:51 [-0400]:
>On Fri, 27 May 2016 15:58:12 +0200
>Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>
>> On -RT we try to acquire sleeping locks which might lead to warnings
>> from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on
>> RT).
>> We don't print in general from a IRQ off region so we should not try
>> this via console_unblank() / bust_spinlocks() as well.
>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> ---
>> kernel/printk/printk.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1502,6 +1502,11 @@ static void call_console_drivers(int lev
>> if (!console_drivers)
>> return;
>>
>> + if (IS_ENABLED(CONFIG_PREEMPT_RT_BASE)) {
>> + if (in_irq() || in_nmi())
>> + return;
>> + }
>> +
>
>We use to have a patch where a console could flag itself as atomic.
>That is, that it doesn't call any sleeping locks. What happened to that.
>
>IIRC, the video console was one such console. Otherwise, we lose out on
>backtraces in irq context.
video, like VT?
The call_console_drivers() does not check such a flag and I don't
remember about removing something like that. I was actually thinking
about adding such a flag… I remember you had something in your tree to
print from IRQ off regions via UART.
We don't print from a context with interrupts disabled or even a preempt
disabled region. In such cases we just wake_up_klogd() and print it
later.
The reason for the patch was the HW/SW lockup detector which comes with
interrupts disabled or NMI context and gets to the console(s). Usually
we defer everything until later except in this case. And I got busted
later in the VT code (and the problem was that one sleeping while atomic
warning which led to more stuff to be printed).
Sebastian
next prev parent reply other threads:[~2016-05-27 14:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 13:58 [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region Sebastian Andrzej Siewior
2016-05-27 14:12 ` Steven Rostedt
2016-05-27 14:56 ` Sebastian Andrzej Siewior [this message]
2016-05-27 15:06 ` Steven Rostedt
2016-05-27 16:13 ` Sebastian Andrzej Siewior
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=20160527145601.GC24120@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox