Re: printk deadlock due to double lock attempt on current CPU's runqueue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-11-10, Sultan Alsawaf <sultan@xxxxxxxxxxxxxxx> wrote:
> On Wed, Nov 10, 2021 at 11:13:37AM +0106, John Ogness wrote:
>> Even after we introduce kthread printers, there will still be
>> situations where direct printing is used: booting (before kthreads
>> exist) and shutdown/suspend/crash situations, when the kthreads may
>> not be active.
>
> Although I'm unaware of any ongoing kthread printer work, I'm curious
> to know how a kthread approach wouldn't employ a try_to_wake_up() from
> directly inside printk(), since the try_to_wake_up() hit from inside
> the fbcon code is what caused my deadlock.

The kthread approach triggers irq_work from printk(). The kthread
printer is then woken from the irq_work.

John Ogness



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux