From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Breno Leitao <leitao@debian.org>,
printk@lists.linux.dev, linux-kernel@vger.kernel.org,
Huacai Chen <chenhuacai@kernel.org>,
WANG Xuerui <kernel@xen0n.name>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Wessel <jason.wessel@windriver.com>,
Daniel Thompson <danielt@kernel.org>,
Douglas Anderson <dianders@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mukesh Kumar Chaurasiya <mchauras@linux.ibm.com>,
Feng Tang <feng.tang@linux.alibaba.com>,
Rio <rioo.tsukatsukii@gmail.com>,
Bradley Morgan <brads@mainlining.org>,
Pnina Feder <pnina.feder@mobileye.com>,
Gal Pressman <gal@nvidia.com>, Petr Pavlu <petr.pavlu@suse.com>,
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Oleg Nesterov <oleg@redhat.com>,
"Cen Zhang (Microsoft)" <blbllhy@gmail.com>,
loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
kgdb-bugreport@lists.sourceforge.net
Subject: Re: [PATCH printk v2 1/6] printk: Introduce and specify flush reasons
Date: Fri, 13 Nov 2026 16:05:46 +0100 [thread overview]
Message-ID: <avcnSjj2P9UfsBn7@pathway.suse.cz> (raw)
In-Reply-To: <20261111181942.593695-2-john.ogness@linutronix.de>
On Wed 2026-11-11 19:25:17, John Ogness wrote:
> Prepare for per-console atomic flushing policies by introducing
> enum pr_flush_reason to classify various reasons for performing a
> printk backlog flush. The reasons are specified for
> printk_trigger_flush() and console_flush_on_panic().
>
> For atomic printing from printk_trigger_flush(), propagate the
> reason down to __nbcon_atomic_flush_pending_con(), where the actual
> atomic flushing is executed.
>
> For legacy printing, use a new global variable @legacy_flush_reason
> to track the reason in case nbcon consoles are using legacy
> printing.
>
> Update all printk_trigger_flush() and console_flush_on_panic()
> call sites as well as any explicit lower-level atomic flush calls
> to specify the reason.
>
> Note that PR_FLUSH_RUNTIME is used for cases where the reason for
> the flush is not clearly defined.
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -145,6 +145,24 @@ void early_printk(const char *s, ...) { }
>
> struct dev_printk_info;
>
> +/**
> + * enum pr_flush_reason - Reason for a flush
> + * @PR_FLUSH_RUNTIME: A flush while the kernel is running
> + * @PR_FLUSH_RESTART: The kernel is ending, but another instance should
> + * follow (reboot, kexec)
> + * @PR_FLUSH_HANG: The kernel is ending and will enter an infinite loop
> + * @PR_FLUSH_KDB: Printing while KDB is active
> + *
> + * Flush reasons are used to determine if unsafe atomic flushing should be
> + * performed, based on individual console policies.
> + */
> +enum pr_flush_reason {
> + PR_FLUSH_RUNTIME = 0,
> + PR_FLUSH_RESTART,
> + PR_FLUSH_HANG,
> + PR_FLUSH_KDB,
> +};
This entire patchset adds a lot of complexity just to enable all
4 new policy flags for netconsole in the last patch.
There already have few dimensions which affect console flushing:
+ console_loglevel
+ nbcon_prio
This patchset adds 8 new terms in pr_flush_reason and
nbcon_unsafe_flush_flags just to explicitly set all
flush_flags in netconsole.
Let's start with pr_flush_reason. I am not sure if it is worth it:
+ PR_FLUSH_RUNTIME is the default
+ PR_FLUSH_RESTART can be detected by system_state > SYSTEM_RUNNING
+ PR_FLUSH_HANG has only one caller currently distinguished by
the global panic_nbcon_allow_unsafe_takeover
+ PR_FLUSH_KDB can be detected by kdb_trap_printk and
kdb_printf_cpu, see vprintk() implementation.
IMHO, it makes things worse because nbcon_atomic_flush_pending() has
to use PR_FLUSH_RUNTIME in vprintk_emit(). But I think that we
would like to flush it the same way as an explicit flush called
in the given context.
Best Regards,
Petr
prev parent reply other threads:[~2026-11-13 15:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 18:19 [PATCH printk v2 0/6] Introduce policies for unsafe flushing John Ogness
2026-11-11 18:19 ` [PATCH printk v2 1/6] printk: Introduce and specify flush reasons John Ogness
2026-11-13 15:05 ` Petr Mladek [this message]
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=avcnSjj2P9UfsBn7@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=blbllhy@gmail.com \
--cc=brads@mainlining.org \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=danielt@kernel.org \
--cc=dianders@chromium.org \
--cc=feng.tang@linux.alibaba.com \
--cc=gal@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=jason.wessel@windriver.com \
--cc=john.ogness@linutronix.de \
--cc=kernel@xen0n.name \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=maddy@linux.ibm.com \
--cc=mchauras@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=oleg@redhat.com \
--cc=petr.pavlu@suse.com \
--cc=pnina.feder@mobileye.com \
--cc=printk@lists.linux.dev \
--cc=ptikhomirov@virtuozzo.com \
--cc=rioo.tsukatsukii@gmail.com \
--cc=ritesh.list@gmail.com \
--cc=rostedt@goodmis.org \
--cc=ryan.roberts@arm.com \
--cc=senozhatsky@chromium.org \
--cc=sshegde@linux.ibm.com \
/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