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

[Sebastian Andrzej Siewior]

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/

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

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

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

Sebastian