All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Breno Leitao <leitao@debian.org>, Petr Mladek <pmladek@suse.com>,
	Kiryl Shutsemau <kas@kernel.org>
Cc: linux-kernel@vger.kernel.org, printk@lists.linux.dev,
	gustavold@gmail.com, samuelcrossley@gmail.com,
	ryan.roberts@arm.com, brads@mainlining.org, x86@kernel.org,
	Breno Leitao <leitao@debian.org>,
	kernel-team@meta.com, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] printk: nbcon: Flush unsafe consoles from printk() in panic
Date: Thu, 05 Nov 2026 15:40:33 +0106	[thread overview]
Message-ID: <87v76bz6rq.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20261102-panic_unsafe_flush-v1-1-12d1e22fd6d8@debian.org>

On 2026-11-02, Breno Leitao <leitao@debian.org> wrote:
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1688,7 +1692,15 @@ static void __nbcon_atomic_flush_pending(u64 stop_seq)
>   */
>  void nbcon_atomic_flush_pending(void)
>  {
> -	__nbcon_atomic_flush_pending(prb_next_reserve_seq(prb));
> +	u64 stop_seq = prb_next_reserve_seq(prb);
> +
> +	__nbcon_atomic_flush_pending(stop_seq, false);
> +
> +	if (panic_on_this_cpu() && oops_in_progress) {
> +		panic_nbcon_allow_unsafe_takeover = true;
> +		__nbcon_atomic_flush_pending(stop_seq, true);
> +		panic_nbcon_allow_unsafe_takeover = false;
> +	}
>  }
>  
>  /**

This part of the patch gave me some ideas. First, I like the idea of
putting the policy handling code inside
nbcon_atomic_flush_pending(). This keeps the code outside of
kernel/printk fairly simple:

1. In emergency sections, printk() is calling
nbcon_atomic_flush_pending(), which always skips
CON_NBCON_ATOMIC_UNSAFE.

2. During panic, printk() is calling nbcon_atomic_flush_pending(), which
via policy could include CON_NBCON_ATOMIC_UNSAFE (in a 2nd internal
loop, after all safe atomic consoles are attempted).

3. After kthreads are shutdown, printk() is calling
nbcon_atomic_flush_pending(), which via policy could include
CON_NBCON_ATOMIC_UNSAFE (in a 2nd internal loop, after all safe atomic
consoles are attempted).

For the above situations, no new flushing calls are needed. But there is
another scenario for CON_NBCON_ATOMIC_UNSAFE (and unsafe printing in
general):

4. If the kernel ends in a way other than the final panic() loop, (for
example kexec, sysrq-r, panic+reboot), the above scenarios do not allow
unsafe printing. For the related code points we could call
nbcon_atomic_flush_unsafe() and it could handle the policy of unsafe
flushing depending on the context, which would allow
CON_NBCON_ATOMIC_UNSAFE to flush here as well.

The unsafe policy flags could be something like:

PANIC_PRINTK
- panic: all printk() calls during panic
- checked in nbcon_atomic_flush_pending() of #2
- if ((policy & PANIC_PRINTK) && panic_in_progress())

NORMAL_FLUSH
- non-panic: atomic flush calls: shutdown, reboot, kexec
- checked in nbcon_atomic_flush_pending() of #3
- checked in nbcon_atomic_flush_unsafe() of #4
- if ((policy & NORMAL_FLUSH) && !panic_in_progress())

PANIC_FLUSH
- panic: unsafe atomic flush calls: reboot, kexec
- checked in nbcon_atomic_flush_unsafe() of #4
- if ((policy & PANIC_FLUSH) && panic_in_progress())

Netconsole originally wanted by default:

    .policy = NORMAL_FLUSH | PANIC_FLUSH,

But this last series shows that netconsole actually wants:

    .policy = NORMAL_FLUSH | PANIC_FLUSH | PANIC_PRINTK,

These are slightly different policies. But as long as printk supports
all 3 policy flags, we do not care which policies are chosen.

I am happy to code up a full implementation if you think this has merit
or you want to see the patch to decide.

John

  reply	other threads:[~2026-11-05 14:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 18:14 [PATCH 0/2] panic: flush unsafe consoles before reboot and kdump Breno Leitao
2026-11-02 18:14 ` [PATCH 1/2] printk: nbcon: Flush unsafe consoles from printk() in panic Breno Leitao
2026-11-05 14:34   ` John Ogness [this message]
2026-11-05 15:37     ` Breno Leitao
2026-11-02 18:14 ` [PATCH 2/2] crash: Flush unsafe consoles before machine_crash_shutdown() Breno Leitao

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=87v76bz6rq.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=brads@mainlining.org \
    --cc=gustavold@gmail.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=printk@lists.linux.dev \
    --cc=ryan.roberts@arm.com \
    --cc=samuelcrossley@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=x86@kernel.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.