Re: printk's threaded legacy console + fbcon => schedule where it should not

[Petr Mladek]

On Tue 2026-01-20 11:08:45, Steven Rostedt wrote:
> On Wed, 14 Jan 2026 15:59:55 +0100
> Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
> 
> > @@ -3362,22 +3362,6 @@ void console_unlock(void)
> >  }
> >  EXPORT_SYMBOL(console_unlock);
> >  
> > -/**
> > - * console_conditional_schedule - yield the CPU if required
> 
> Egad! That goes all the way back to 2002:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=a880f45a48be2956d2c78a839c472287d54435c1
>
> > - *
> > - * If the console code is currently allowed to sleep, and
> > - * if this CPU should yield the CPU to another task, do
> > - * so here.
> > - *
> > - * Must be called within console_lock();.
> > - */
> > -void __sched console_conditional_schedule(void)
> > -{
> > -	if (console_may_schedule)
> > -		cond_resched();
> > -}
> > -EXPORT_SYMBOL(console_conditional_schedule);
> 
> I'm assuming this likely isn't needed anymore. I don't know of any reason
> it needs to stay.

I know that there was a plan to get rid of cond_resched().
But what is the status now, please?

I still see more that 1k cond_resched() calls in the code:

  $> git grep cond_resched\(\) | grep "\.c:" | wc -l
  1263

And config PREEMPT_VOLUNTARY still talks about the explicit
preemption points.

> Should we just remove it and see what breaks?

Honestly, I do not feel comfortable with removing it. It is true that
it has no effect in the printk() code path. But the vt code is used
also when working on the terminal.

The vt code still uses console_lock() because it was intertwined
with printk console code since very old days. console_lock is a kind
of big kernel lock there.


Alternative solution is to get rid of the spin_trylock(). The only
purpose is to prevent race in console_flush_on_panic(). It used
to be a simple bit operation. The spin_lock() was added just to
get barriers right. But we have a great atomic_t API these days.

IMHO, it is a win-win solution because a preemptive context is
always better.

What about?