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: <87a5j0kesc.fsf@jogness.linutronix.de>
Date: Mon, 01 Jul 2024 23:07:23 +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

On 2024-07-01, Petr Mladek <pmladek@...e.com> wrote:
>> 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.
>
> Is this really the case for all boot consoles?
>
> I had the feeling that some boot consoles actually used port->lock.
> And for example, register_earlycon() is initializing this spin lock.

Doing a naive search, it seems like there are a few that do some spin
locking:

- alpha/kernel/srmcons.c
- tty/hvc/hvc_xen.c
- tty/mips_ejtag_fdc.c
- usb/early/xhci-dbc.c

I will need to look at these in more detail.

>> - We get true synchronous printing when using boot consoles (which
>>   should make peterz happy).
>
> Well, Peter's mode is really special because it is done without
> the console_lock(). Every printk() is flushing its own message
> to the console. Parallel printk()'s are busy waiting for each other.

This is also what I would like to see. For debugging purposes (which is
the purpose of CON_BOOT) this mode of operation is probably preferred.

>> 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().
>
> The sync mode would be nice.
>
> Just to be sure. I guess that you are talking about a sync mode
> using some trylock mechanism where the current owner would be
> responsible for flushing everything.
>
> Peter Zijlstra's mode (serialized printk()) is easy to implement
> and might be needed in some situations. But I am not sure if
> it would be good enough for most other users preferring the
> current "synchronous" output.

I have always envisioned it being a true sync mode. Each console has its
own nbcon state. So if it was set to sync mode, vprintk_emit() could
local_irq_save() and then busy-wait until it acquires the nbcon state
for that console. There would be no handovers and no relying on another
context to print your message. It would be straight forward and truly
synchronous (for that console). Back to the roots of printk().

> Well, let's see what people request after they get some experience
> with the first nbcon consoles and kthreads.