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: <ZoPESELkawZhA24J@pathway.suse.cz>
Date: Tue, 2 Jul 2024 11:11:36 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
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 Mon 2024-07-01 23:07:23, John Ogness wrote:
> 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.

This looks like a non-trivial thing. I assume that you would do this later.
We probably do not want to complicate/delay the current patchset by this.

> >> - 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.

Makes sense. And it would be great when it was enough.

Well, I could also imagine that a non-serialized printk() might be
useful to debug some races in the code before the printk
kthreads are started.

Another scenario where a synchronized printk might be useful is
a sudden death. In this case, the "synchronous" printk would
be needed all the time. People might prefer the current
legacy mode where printk works synchronously most of the time
but it is not fully serialized.

Honestly, I do not know what people want. There always will be
usecase where some mode would be needed or work better.
We should be prepared for the situation when people would
want to keep a mode which has been used last 25+ years.

> >> 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().

I see this as yet another feature which might be introduced later.
In this patchset, I would keep the legacy behavior when boot
consoles are registered.

Best Regards,
Petr