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

[Petr Mladek]

On Wed 2026-01-21 14:57:37, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 14:43:45 [+0100], Petr Mladek wrote:
> > I know that there was a plan to get rid of cond_resched().
> > But what is the status now, please?
> 
> It is slowly moving => https://lore.kernel.org/all/20251219101502.GB1132199@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

Good to know.

> > 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.
> 
> Do you a have path which loops and would mandate it? I found a few which
> do not matter and have their own cond_resched() around. So I don't see a
> reason to keep it. And I found one which breaks things so a removal
> makes sense.

Could anyone from VT guys comment on it, please?

> > 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.
> 
> So why do we keep warts again? Just because it *might* be required?
> Keeping things preemptible makes sense but this is locking with no
> annotation what so ever.

Well, the current locking is documented but it creates false
positives. The "printing_lock" is taken on a single place
using spin_trylock(). Nobody would ever spin on it. So
sleeping is perfectly fine.

> Again. printk has its cond_resched, the tty has it, too.
> I'm with Steven on the removal side.

As I said, the cond_resched() does not have any effect from
the printk() code path. But the other VT paths might rely on it.
If VT-guys are willing to take the risk and remove it
then I am fine with it.

Best Regards,
Petr