Re: [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code

[Petr Mladek]

On Wed 2026-07-08 16:59:57, John Ogness wrote:
> On 2026-07-08, Petr Mladek <pmladek@xxxxxxxx> wrote:
> >> The synchronous mode would rely on the driver being nbcon. I envision
> >> something like this:
> >>
> >> ---- BEGIN SYNC IDEA ----
> >> --- a/kernel/printk/nbcon.c
> >> +++ b/kernel/printk/nbcon.c
> >> @@ -1200,7 +1200,7 @@ static bool nbcon_kthread_should_wakeup(struct console *con, struct nbcon_contex
> >>  	cookie = console_srcu_read_lock();
> >>  
> >>  	flags = console_srcu_read_flags(con);
> >> -	if (console_is_usable(con, flags, false)) {
> >> +	if (!(flags & CON_SYNC) &&  console_is_usable(con, flags, false)) {
> >
> > The dependency on con->flags means that the sync mode can be entered
> > only in task context where synchronize_srcu() can be called. It might
> > be good enough. But I am afraid that people are creative and would
> > like to have even atomic variant sooner or later.
> 
> You mean it can only be _modified_ in task context. Yes. I expect it is
> either specified as a boot arg or modified via some sysfs interface.

Makes sense.

> > Also it will do the flush in NORMAL_PRIO which is good. But it might
> > fail to get the context ownership when it is blocked, for example,
> > by uart_port_lock() which might be even sleepable context in
> > PREEMPT_RT kernel.
> 
> Indeed. This is the same limitation of the atomic printing in
> general. But I do not think this can be worked around during normal
> operation. Ignoring locks is not an option.

Let's see how it works in practice. But it might work pretty well.

Now, the question is how to move forward. It would be nice to
have the sync mode available before we add this boot/printk_delay
clean up.

Would you have time to prepare and send a patch anytime soon, please?

Or I wonder whether Andrew Murray might try to create a patch
based on your "SYNC IDEA".

Best Regards,
Petr