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