linux-kernel - Re: [PATCH printk v2 12/18] printk: Add kthread for all legacy consoles

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: <874j9dxdr0.fsf@jogness.linutronix.de>
Date: Fri, 28 Jun 2024 18:02:19 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt
 <rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v2 12/18] printk: Add kthread for all legacy
 consoles

Hi Petr,

Your comments are sending me into deep thought about this
situation. Some more comments from me...

On 2024-06-28, John Ogness <john.ogness@...utronix.de> wrote:
> On PREEMPT_RT, legacy consoles are not allowed to print from
> non-preemptible contexts because they use spinlocks (rtmutexes).

The above statement is not true for legacy _boot_ consoles
(earlycon/earlyprintk). These are lockless and are intended to execute
from any context (except NMI due to semaphore limitations).

I hate boot consoles because they don't use the Linux driver model and
rely fully on external synchronization. This has made the rework very
difficult and is actually the core reason why our work was reverted back
in 5.19-rc4. But for debugging early boot problems, they are quite
useful.

I have a new proposal. What if we allow boot consoles to always print in
the caller context (for any preemption model)? I hacked a quick test
together by providing console_flush_all() an extra argument for printing
_only_ on boot consoles. Then in vprintk_emit(), I always do a
boot-console-only-flush (under console_trylock) after storing the record
in the ringbuffer.

For PREEMPT_RT this is horrible. But I am OK with mandating that RT
scheduling cannot be guaranteed with boot consoles (just as it is
currently mandated that RT scheduling cannot be guaranteed in emergency
situations). Since the boot consoles are lockless, they pose no deadlock
threat to RT.

This has some nice features:

- We get early debugging in all preemption models.

- We get true synchronous printing when using boot consoles (which
  should make peterz happy).

- Boot consoles are then horrible enough that options such as
  "keep_bootcon" will really be avoided unless debugging kernel issues.

>From the tests I have run so far, it looks good.

Looking to the future, I think this would also provide an excellent
foundation for the "sync" console option I would like. For nbcon
consoles with the "sync" option specified, it would work the same way,
flushing boot consoles and nbcon consoles directly in vprintk_emit().

Thoughts?

John