All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>,
	Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: panic context: was: Re: [PATCH printk v2 04/11] printk: nbcon: Provide functions to mark atomic write sections
Date: Fri, 6 Oct 2023 14:53:36 +0200	[thread overview]
Message-ID: <ZSADUKp8oJ2Ws2vC@alley> (raw)
In-Reply-To: <87h6n5teos.fsf@jogness.linutronix.de>

(2nd attempt with with Linus really in Cc).

Adding Linus into Cc. I would like to be sure about the flushing
of atomic consoles in panic context.

> During the demo at LPC2022 we had the situation that there was a large
> backlog when a WARN was hit. With current mainline the first line of the
> WARN is put into the ringbuffer and then the entire backlog is flushed
> before storing the rest of the WARN into the ringbuffer. At the time it
> was obvious that we should finish storing the WARN message and then
> start flushing the backlog.

This talks about the "emergency" context (WARN/OOPS/watchdog).
The system might be in big troubles but it would still try to continue.

Do we really want to defer the flush also for panic() context?

I ask because I was not on LPC 2022 in person and I do not remember
all details.

Anyway, the deferred flush works relatively well for the "emergency" context:

   + flushed from nbcon_atomic_exit()
   + printk kthread might emit the messages while they are being added

But it is tricky in panic(), see 8th patch at
https://lore.kernel.org/r/20230919230856.661435-9-john.ogness@linutronix.de

   + nbcon_atomic_exit() is called only in one code path.

   + nbcon_atomic_flush_all() is used in other paths. It looks like
     a "Whack a mole" game to me.

   + messages are never emitted by printk kthread either because
     CPUs are stopped or the kthread is not allowed to get the lock[*]

I see only one positive of the explicit flush. The consoles would
not delay crash_exec() and the crash dump might be closer to
the point where panic() was called.

Otherwise I see only negatives => IMHO, we want to flush atomic
consoles synchronously from printk() in panic().

Does anyone really want explicit flushes in panic()?

[*] Emitting messages is explicitly blocked on non-panic CPUs. It
    increases the change that panic-CPU would be able to take
    the console lock the safe way.

Best Regards,
Petr

  parent reply	other threads:[~2023-10-06 12:53 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 23:08 [PATCH printk v2 00/11] wire up nbcon atomic printing John Ogness
2023-09-19 23:08 ` [PATCH printk v2 01/11] printk: Make console_is_usable() available to nbcon John Ogness
2023-09-22  8:33   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 02/11] printk: Let console_is_usable() handle nbcon John Ogness
2023-09-22  8:37   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 03/11] printk: Add @flags argument for console_is_usable() John Ogness
2023-09-22  8:41   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 04/11] printk: nbcon: Provide functions to mark atomic write sections John Ogness
2023-09-22  9:33   ` Petr Mladek
2023-09-25  9:25     ` John Ogness
2023-09-25 16:04       ` Petr Mladek
2023-10-05 12:51         ` John Ogness
2023-10-06 12:51           ` panic context: was: " Petr Mladek
2023-10-06 12:53           ` Petr Mladek [this message]
2023-10-08 10:13             ` John Ogness
2023-10-09 15:32               ` Petr Mladek
2023-10-10 16:02                 ` John Ogness
2023-10-16  8:58               ` Dave Young
2023-10-16  8:58                 ` Dave Young
2023-10-16 10:09                 ` John Ogness
2023-10-16 10:09                   ` John Ogness
2023-10-06 15:52           ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 05/11] printk: nbcon: Provide function for atomic flushing John Ogness
2023-09-22 12:32   ` Petr Mladek
2023-09-25 11:11     ` John Ogness
2023-09-19 23:08 ` [PATCH printk v2 06/11] printk: nbcon: Wire up nbcon console " John Ogness
2023-09-22 17:41   ` Petr Mladek
2023-09-25 13:37     ` John Ogness
2023-09-26 12:14       ` Petr Mladek
2023-10-05 13:59         ` John Ogness
2023-09-19 23:08 ` [PATCH printk v2 07/11] printk: nbcon: Wire up nbcon into console_flush_all() John Ogness
2023-09-26 11:34   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 08/11] panic: Add atomic write enforcement to warn/panic John Ogness
2023-09-27 12:02   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 09/11] panic: Add atomic write enforcement to oops John Ogness
2023-09-19 23:36   ` John Ogness
2023-09-20 13:28   ` Andy Shevchenko
2023-09-20 14:20     ` John Ogness
2023-09-20 14:45       ` Andy Shevchenko
2023-09-27 13:15   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 10/11] rcu: Add atomic write enforcement for rcu stalls John Ogness
2023-09-27 15:00   ` Petr Mladek
2023-09-19 23:08 ` [PATCH printk v2 11/11] lockdep: Add atomic write enforcement for lockdep splats John Ogness
2023-09-29  8:31   ` 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=ZSADUKp8oJ2Ws2vC@alley \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linuxfoundation.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.