Re: [PATCH printk v1 11/13] printk: reimplement console_lock for proper kthread support
From: Petr Mladek
Date: Fri Mar 11 2022 - 11:17:56 EST
On Fri 2022-03-11 14:34:40, John Ogness wrote:
> On 2022-03-11, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > But it does not help when the lock was taken
> > via console_trylock() from printk(). It might mean that
> > the forward progress might not be guaranteed in the direct mode
> > (early boot, panic, ...).
>
> How is the console_trylock() case different from current mainline now?
> As I mentioned above, the kthreads can block console_trylock(), but so
> can a console_lock() currently in mainline.
CPU0 CPU1 CPU2
printk()
// direct mode allowed
console_trylock()
console_unlock()
console_flush_all()
printk_direct_enter()
allows_direct_printing() -> false;
break;
__console_unlock()
wakeup_klogd()
// woken printk_khread
console_thread_printing_enter()
printk_direct_exit()
console_trylock()
atomic_tryblock()
//fails because thread active
return;
printk_direct_enter()
console_thread_printing_exit()
// sleep because
atomic_read(&printk_direct) is not
zero
Result: nobody prints
Note: The thread will actually not sleep because printk_should_wake()
does not check atomic_read(&printk_direct).
But it is a bug. Active thread should check it and allow
entering direct mode.
Note2: Even when one printk thread flushes the messages. There might
be other thread that will never get scheduled a nobody would
printk the messages on the related console.
This is the race that I see with console_trylock(). IMHO, if we solve
this race then we do not need console_trylock_sched().
Well, I might be wrong. It is Friday evening. I still do not have
the entire picture. I probably should have waited for Monday.
I am sure that I misunderstood several things, including wait_event()
API or CON_DIRECT flag. But the above race looks real. And it somehow
supports my feeling about that there are some races that can't be
solved by console_trylock_sched().
Best Regards,
Petr