All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: paulmck@kernel.org
Cc: linux-kernel@vger.kernel.org, frederic@kernel.org,
	pmladek@suse.com, Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [BUG] 8e274732115f ("printk: extend console_lock for per-console locking")
Date: Mon, 13 Jun 2022 11:10:19 +0206	[thread overview]
Message-ID: <87tu8pgcj0.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20220613042937.GZ1790663@paulmck-ThinkPad-P17-Gen-1>

On 2022-06-12, "Paul E. McKenney" <paulmck@kernel.org> wrote:
>> As I suspected, the final printk's cannot direct print because the
>> kthread was printing. Using the below patch did seem to address your
>> problem. But this is probably not the way forward.
>
> When I apply it, I still lose output, perhaps due to different timing?
> Doing the pr_flush(1000, true) just before the call to kernel_power_off()
> has been working quite well thus far, though.

Your pr_flush() is appropriate for your RCU tests, but this is a problem
in general that needs to be addressed. I suppose we should start a new
thread for that. ;-)

During development we experimented with the idea of kthreads pausing
themselves whenever direct printing is activated. It was racey because
there are situations when direct printing is only temporarily active and
it was hard to coordinate who prints when direct printing becomes
inactive again. So we dropped that idea. However, in this situation the
system will not be disabling direct printing.

@Paul, can you try the below change instead? Until this has been
officially solved, you probably want to keep your pr_flush()
solution. (After all, that is exactly what pr_flush() is for.) But it
would be helpful if you could run this last test for us.

@Petr, I like the idea of the kthreads getting out of the way rather
than trying to direct print themselves (for this situation). It still
isn't optimal because that final pr_emerg("Power down\n") might come
before the kthread has finished its current line. But in that case the
kthread may not have much a chance to finish the printing anyway.

John Ogness

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index ea3dd55709e7..45c6c2b0b104 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3729,7 +3729,9 @@ static bool printer_should_wake(struct console *con, u64 seq)
 		return true;
 
 	if (con->blocked ||
-	    console_kthreads_atomically_blocked()) {
+	    console_kthreads_atomically_blocked() ||
+	    system_state > SYSTEM_RUNNING ||
+	    oops_in_progress) {
 		return false;
 	}
 

  reply	other threads:[~2022-06-13  9:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 20:50 [BUG] 8e274732115f ("printk: extend console_lock for per-console locking") Paul E. McKenney
2022-06-12 13:23 ` Paul E. McKenney
2022-06-12 16:03   ` John Ogness
2022-06-12 16:30     ` Paul E. McKenney
2022-06-13 11:01     ` Petr Mladek
2022-06-13  2:12 ` John Ogness
2022-06-13  4:29   ` Paul E. McKenney
2022-06-13  9:04     ` John Ogness [this message]
2022-06-13 10:32       ` Petr Mladek
2022-06-13 15:07         ` Petr Mladek
2022-06-13 15:51           ` Paul E. McKenney
2022-06-13 15:44       ` Paul E. McKenney
2022-06-13 10:50 ` 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=87tu8pgcj0.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /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.