LKML Archive on
help / color / mirror / Atom feed
From: Petr Mladek <>
To: Daniel Vetter <>
Cc: Intel Graphics Development <>,
	DRI Development <>,
	Daniel Vetter <>,
	Peter Zijlstra <>,
	Ingo Molnar <>, Will Deacon <>,
	Sergey Senozhatsky <>,
	Steven Rostedt <>,
	John Ogness <>,
	Chris Wilson <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH] RFC: console: hack up console_lock more v3
Date: Fri, 10 May 2019 11:15:37 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu 2019-05-09 18:43:12, Daniel Vetter wrote:
> One thing to keep in mind is that the kernel is already dying, and
> things will come crashing down later on

This is important information. I havn't seen it mentioned earlier.

> (I've seen this only in dmesg
> tails capture in pstore in our CI, i.e. the box died for good). I just
> want to make sure that the useful information isn't overwritten by
> more dmesg splats that happen as a consequence of us somehow trying to
> run things on an offline cpu. Once console_unlock has completed in
> your above backtrace and the important stuff has gone out I'm totally
> fine with the kernel just dying. Pulling the wake_up_process out from
> under the semaphore.lock is enough to prevent lockdep from dumping
> more stuff while we're trying to print the important things,

With the more stuff you mean the lockdep splat? If yes, it might
make sense to call debug_locks_off() earlier in panic().

> and I think the untangling of the locking hiararchy is useful irrespective
> of this lockdep splat. Plus Peter doesn't sound like he likes to roll
> out more printk_deferred kind of things.
> But if you think I should do the printk_deferred thing too I can look
> into that. Just not quite sure what that's supposed to look like now.

Your patch might remove the particular lockdep splat. It might be
worth it (Peter mentioned also an optimization effect). Anyway
it will not prevent the deadlock.

The only way to avoid the deadlock is to use printk_deferred()
with the current printk() code.

Finally, I have recently worked on similar problem with dying system.
I sent the following patch for testing. I wonder if it might be
acceptable upstream:

From: Petr Mladek <>
Subject: sched/x86: Do not warn about offline CPUs when all are being stopped
Patch-mainline: No, just for testing
References: bsc#1104406

The warning about rescheduling offline CPUs cause dealock when
the CPUs need to get stopped using NMI. It might happen with
logbuf_lock, locks used by console drivers, especially tty.
But it might also be caused by a registered kernel message
dumper, for example, pstore.

The warning is pretty common when there is a high load and
CPUs are being stopped by native_stop_other_cpus(). But
they are not really useful in this context. And they scrolls
the really important messages off the screen.

We need to fix printk() in the long term. But disabling
the message looks reasonable at least in the meantime.

Signed-off-by: Petr Mladek <>
 arch/x86/kernel/smp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -124,7 +124,8 @@ static bool smp_no_nmi_ipi = false;
 static void native_smp_send_reschedule(int cpu)
-	if (unlikely(cpu_is_offline(cpu))) {
+	if (unlikely(cpu_is_offline(cpu) &&
+		     atomic_read(&stopping_cpu) < 0)) {
 		WARN(1, "sched: Unexpected reschedule of offline CPU#%d!\n", cpu);

  reply	other threads:[~2019-05-10  9:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-09 12:09 Daniel Vetter
2019-05-09 12:21 ` Chris Wilson
2019-05-09 12:31 ` Peter Zijlstra
2019-05-09 13:06   ` Daniel Vetter
2019-05-09 13:36     ` Peter Zijlstra
2019-05-09 14:56 ` Petr Mladek
2019-05-09 16:43   ` Daniel Vetter
2019-05-10  9:15     ` Petr Mladek [this message]
2019-05-10  9:51       ` Sergey Senozhatsky
2019-05-10 15:05       ` Daniel Vetter
2019-05-09 20:06 ` [PATCH] kernel/locking/semaphore: use wake_q in up() Daniel Vetter
2019-05-10  5:50   ` Sergey Senozhatsky
2019-05-10  7:51     ` Daniel Vetter
2019-05-10  9:28   ` Petr Mladek
2019-05-10 15:20     ` Daniel Vetter
2019-05-15 11:53       ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] RFC: console: hack up console_lock more v3' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).