linux-kernel - Re: [RFC PATCH v2] printk: console: Allow each console to have its own loglevel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Ys7Xe8iSOYzmQeIu@chrisdown.name>
Date:   Wed, 13 Jul 2022 15:32:27 +0100
From:   Chris Down <chris@...isdown.name>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>, kernel-team@...com
Subject: Re: [RFC PATCH v2] printk: console: Allow each console to have its
 own loglevel

Petr Mladek writes:
>The problem is clear. But the big part of the problem is that printk()
>tries to show the messages on all consoles immediately.
>
>I wonder how much the per-console loglevel would be needed
>when the console handling is offloaded to per-console kthreads, see
>https://lore.kernel.org/all/20220421212250.565456-1-john.ogness@linutronix.de/
>It causes that printk() should "never" block and each console might
>run on its own speed.
>
>It still might be useful from some reasons:
>
>    + Serial consoles might miss messages because the old messages are
>      over-written before they reach the console. It might be solved
>      by big enough buffer.
>
>    + printk() still tries to show the messages immediately in some
>      critical situations, for example, early boot, watchdog warnings,
>      suspend, reboot, OOps, panic(). The slow consoles might still
>      cause stalls and put the system into its knees.
>
>    + People might need to explicitly disable the kthreads, for
>      example, when debugging a situation when kthreads are not
>      scheduled.

Indeed. In addition to these, there are cases (like the pstore case mentioned 
by Vincent) where we want to bump the console loglevel up to the maximum for 
debugging, but it still doesn't make sense to emit it over all consoles -- 
especially netconsoles where processing capacity on the netconsole 
receiver/server is likely limited. The same is true for things like baseboard 
management controllers where they may blindly store the console output in a 
similar fashion.

The kthread offloading is definitely going to help a lot here here, but to 
capably be able to use netconsole in prod we're going to need both.

>PS: I am sorry for the late response. I am still snowed under
>many tasks. The printk kthreads are complicated and need
>a lot of attention. Plus there was a sickness, vacations,
>and other tasks.

Don't worry, I totally understand :-) I really appreciate you getting back.