Re: [PATCH v8 00/21] printk: console: Per-console loglevels

[Petr Mladek]

On Fri 2025-11-28 03:43:05, Chris Down wrote:
> v8:
> 
> - Fully resolve loglevel before printk_delay to aid LOGLEVEL_DEFAULT
> - Prioritise user-specified console options over SPCR/DT
> - Synchronise console unregistration against atomic flushers in nbcon
> - Optimise printk_delay to avoid SRCU walk when no delay set
> - Restored accidentally deleted comment in console_srcu_read_flags
> - Removed extra put_device() in console unregistration
> - Changed open coded console_srcu_read_lock usage to functions
> - Removed redundant newcon->classdev = NULL initialisation
> - Fixed off-by-one errors in loglevel examples in docs (4 vs >4)
> - In docs clarified "messages won't appear" edge case
> - In docs, rewrote performance impact section per Petr
> - In docs, removed obsolete minimum_console_loglevel section
> - Removed redundant newcon->level init in try_enable_preferred_console
> - Split up commits some more where reasonable (with tags kept)
> - Make SYSLOG_ACTION_CONSOLE_{ON,OFF} only restore IPCL when they did it
> - Drop sysrq loglevel overrides, just use ignore_per_console_loglevel
> - Set options to NULL if empty so drivers keep baud
> - Copy console= option strings before stripping loglevel for mips/jazz
> - Initialise consoles with LOGLEVEL_DEFAULT so sysfs never exposes 0
> - Clamp sysrq loglevels

Heh, there were more changes than I expected ;-)

I am done with the review. The biggest remanining question is what to
do with printk_delay(). This patchset shows that the current approach
(call it in vprintk_emit()) brings a lot of problems. But it never
worked. And it is an orthogonal problem to the per-console loglevel
feature.

I would suggest to keep it simple and remove most of the
printk_delay()-related patches for now. We should solve this
separately. I would try to move printk_delay() to the console
flush code paths, as proposed at
https://lore.kernel.org/all/aTrjHxZN_RpSw9lK@pathway/
I could implement this approach myself if you would prefer it.

Best Regards,
Petr