Message-ID: <ZoLMRQhrwZnWMuj9@pathway.suse.cz>
Date: Mon, 1 Jul 2024 17:33:25 +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 Fri 2024-06-28 18:02:19, John Ogness wrote:
> 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.

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.

> This has some nice features:
> 
> - We get early debugging in all preemption models.

It would be great.

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

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

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.

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

Best Regards,
Petr

Powered by blists - more mailing lists