public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Chris Down <chris@chrisdown.name>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Tony Lindgren <tony.lindgren@linux.intel.com>,
	kernel-team@fb.com
Subject: Re: [PATCH v8 01/21] printk: Fully resolve loglevel before deciding printk delay suppression
Date: Thu, 11 Dec 2025 16:28:31 +0100	[thread overview]
Message-ID: <aTrjHxZN_RpSw9lK@pathway> (raw)
In-Reply-To: <aTraDoF1kBIWO_c2@pathway>

On Thu 2025-12-11 15:49:54, Petr Mladek wrote:
> On Tue 2025-12-09 17:40:11, Petr Mladek wrote:
> > On Fri 2025-11-28 03:43:12, Chris Down wrote:
> > > When printk_delay() is called from vprintk_emit(), the level argument
> > > may be LOGLEVEL_DEFAULT (-1) if the loglevel was not explicitly provided
> > > by the caller.
> > > 
> > > If printk_delay() relies on comparing level against the console loglevel
> > > (e.g. for suppression), receiving -1 results in incorrect behaviour
> > > because -1 is treated as a high priority (so not suppressed), causing
> > > unnecessary delays for default-level messages.
> > 
> > Great catch!
> > 
> > > Parse the format string prefix to resolve the actual loglevel before
> > > passing it to printk_delay().
> > > 
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -2179,6 +2179,32 @@ u16 printk_parse_prefix(const char *text, int *level,
> > >  	return prefix_len;
> > >  }
> > >  
> > > +/**
> > > + * printk_resolve_loglevel - Resolve the effective loglevel for a message
> > > + *
> > > + * @facility:	The log facility (0 for kernel messages)
> > > + * @level:	The initial loglevel, may be LOGLEVEL_DEFAULT
> > > + * @fmt:	The format string, potentially containing a loglevel prefix
> > > + *
> > > + * Determines the actual loglevel to use for a printk message. If the level
> > > + * is LOGLEVEL_DEFAULT and the facility indicates a kernel message, parses
> > > + * the format string prefix to extract an embedded loglevel. If no loglevel
> > > + * is found, falls back to the default_message_loglevel.
> > > + *
> > > + * Return: The resolved loglevel value
> > > + */
> > > +static inline int printk_resolve_loglevel(int facility, int level,
> > > +					  const char *fmt)
> > > +{
> > > +	if (facility == 0 && level == LOGLEVEL_DEFAULT && fmt)
> > > +		printk_parse_prefix(fmt, &level, NULL);
> > > +
> > > +	if (level == LOGLEVEL_DEFAULT)
> > > +		level = default_message_loglevel;
> > 
> > This is not ideal:
> > 
> >  1. It more or less duplicates the code from vprintk_store().
> > 
> >  2. It does not handle loglevel passed via parameter, for example, see
> >     _btrfs_printk() which calls _printk("%sBTRFS %s: %pV\n", lvl, type, &vaf).
> >     Note that vprintk_store() calls vsnprintf() before checking the loglevel.
> > 
> > > +	return level;
> > > +}
> > 
> > Alternative solutions:
> > 
> >   A. We might call vsnprintf() one more times here.
> > 
> >      It is ugly but we could do it only when anyone wants a delay.
> >      Also this is not easy because we would need to check printk_delay_msec,
> >      boot_delay, and system_state.
> > 
> >      Anyway, this solution would need some refactoring in printk_delay()
> >      and vprintk_store() to avoid code duplication.
> 
> Even more duplicated code was added by later patches.
> 
> I tried to implement this alternative solution and remove all code
> duplication. But I think that this is a wrong way after all:

The solution is not good:

  + It adds a lot of code complexity and one more vscnprintf() is needed.

  + One more vscnprintf() call is needed.

  + It still does not work properly. For example, backtraces from
    all CPUs (SysRq l) prints the entire backtrace at once because
    the console flush is delayed. The same problem will happen for
    any delayed messages, e.g. during early boot before the 1st console
    is registered.

 >   B. We could move printk_delay().
> > 
> >      It should be called before storing the message. Otherwise, we
> >      would need to call it from various console flush calls. And there
> >      are many flush paths. Also the message might get lost when
> >      consoles fall far behind.

I looked at this variant and I think that it might be much better
after all. IMHO, it should be enough to move printk_delay() from
vprintk_emit() to:

   + console_flush_one_record()
   + nbcon_emit_one()

Note that it is possible only in 6.19. It includes some refactoring
which allows to release locks between each record in both legacy
and nbcon code paths. One piece is still missing, see
https://lore.kernel.org/r/20251202135832.156559-1-pmladek@suse.com

I would suggest to solve this separately. The printk_delay() never
worked correctly. And it seems to be a more complex problem.

I mean. Let's keep this patchset only for adding per-console loglevels.
Do only the bare minimum (like in v7) and remove the rather complex
improvements added in v8.

Or we could move the printk_delay to console emit code paths first.
And rebase the per-console patchset on top of it.

Sigh, I do not want to block the per-console patchset once again.
But the printk_delay()-related changes in v8 are too hacky my taste.

Best Regards,
Petr

  reply	other threads:[~2025-12-11 15:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27 19:43 [PATCH v8 00/21] printk: console: Per-console loglevels Chris Down
2025-11-27 19:43 ` [PATCH v8 01/21] printk: Fully resolve loglevel before deciding printk delay suppression Chris Down
2025-12-09 16:40   ` Petr Mladek
2025-12-11 14:49     ` Petr Mladek
2025-12-11 15:28       ` Petr Mladek [this message]
2025-11-27 19:43 ` [PATCH v8 02/21] printk: Avoid spuriously delaying messages not solicited by any console Chris Down
2025-11-27 19:43 ` [PATCH v8 03/21] printk: Prioritise user-specified configuration over SPCR/DT Chris Down
2025-12-10 14:38   ` Petr Mladek
2025-11-27 19:43 ` [PATCH v8 04/21] printk: Use effective loglevel for suppression and extended console state Chris Down
2025-11-27 19:43 ` [PATCH v8 05/21] printk: console: Add per-console loglevel support to struct console Chris Down
2025-11-27 19:43 ` [PATCH v8 06/21] printk: nbcon: Synchronise console unregistration against atomic flushers Chris Down
2025-12-10 15:12   ` Petr Mladek
2025-11-27 19:43 ` [PATCH v8 07/21] printk: Introduce per-console loglevel support Chris Down
2025-11-27 19:43 ` [PATCH v8 08/21] printk: Iterate registered consoles for delay suppression decisions Chris Down
2025-11-27 19:43 ` [PATCH v8 09/21] printk: Optimise printk_delay() to avoid walking consoles under SRCU Chris Down
2025-12-11 14:37   ` Petr Mladek
2025-11-27 19:43 ` [PATCH v8 10/21] printk: Add synchronisation for concurrent console state changes Chris Down
2025-11-27 19:43 ` [PATCH v8 11/21] printk: Add ignore_per_console_loglevel module parameter Chris Down
2025-11-27 19:43 ` [PATCH v8 12/21] printk: Ensure sysrq output bypasses per-console filtering Chris Down
2025-11-27 19:44 ` [PATCH v8 13/21] printk: Toggle ignore_per_console_loglevel via syslog Chris Down
2025-11-27 19:44 ` [PATCH v8 14/21] printk: console: Introduce sysfs interface for per-console loglevels Chris Down
2025-12-12 14:04   ` Petr Mladek
2025-11-27 19:44 ` [PATCH v8 15/21] printk: sysrq: Clamp console loglevel to valid range Chris Down
2025-12-12 14:10   ` Petr Mladek
2025-11-27 19:44 ` [PATCH v8 16/21] printk: Constrain hardware-addressed console checks to name position Chris Down
2025-11-27 19:44 ` [PATCH v8 17/21] printk: Support setting initial console loglevel via console= on cmdline Chris Down
2025-11-27 19:44 ` [PATCH v8 18/21] printk: Deconstruct kernel.printk into discrete sysctl controls Chris Down
2025-12-12 15:24   ` Petr Mladek
2025-12-15 10:08     ` Joel Granados
2025-12-15 16:09       ` Petr Mladek
2025-11-27 19:44 ` [PATCH v8 19/21] printk: docs: Add comprehensive guidance for per-console loglevels Chris Down
2025-12-12 15:32   ` Petr Mladek
2025-11-27 19:44 ` [PATCH v8 20/21] printk: Deprecate the kernel.printk sysctl interface Chris Down
2025-12-12 15:51   ` Petr Mladek
2025-12-15  9:52     ` Joel Granados
2025-12-15 16:06       ` Petr Mladek
2025-12-17 11:47         ` Joel Granados
2025-12-17 14:33           ` Geert Uytterhoeven
2025-12-17 16:04             ` Steven Rostedt
2025-12-17 20:23               ` Joel Granados
2025-11-27 19:44 ` [PATCH v8 21/21] printk: Purge default_console_loglevel Chris Down
2025-12-12 16:11 ` [PATCH v8 00/21] printk: console: Per-console loglevels 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=aTrjHxZN_RpSw9lK@pathway \
    --to=pmladek@suse.com \
    --cc=chris@chrisdown.name \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.ogness@linutronix.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tony.lindgren@linux.intel.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