On (10/19/16 00:40), Sergey Senozhatsky wrote: [..] > Deadlock scenarios that printk_safe can handle: > > a) printk recursion from logbuf_lock spin_lock section in printk() > printk() > raw_spin_lock(&logbuf_lock); > WARN_ON(1); > raw_spin_unlock(&logbuf_lock); > > b) printk from sem->lock spin_lock section > printk() > console_trylock() > down_trylock() > raw_spin_lock_irqsave(&sem->lock, flags); > WARN_ON(1); > raw_spin_unlock_irqrestore(&sem->lock, flags); > > c) printk from logbuf_lock spin_lock section in console_unlock() > printk() > console_unlock() > raw_spin_lock(&logbuf_lock); > WARN_ON(1); > raw_spin_unlock(&logbuf_lock); > > d) printk from ->pi_lock from semaphore up > printk() > console_unlock() > up() > try_to_wake_up() > raw_spin_lock_irqsave(&p->pi_lock, flags); > WARN_ON(1); > raw_spin_unlock_irqrestore(&p->pi_lock, flags);
and e) anything from call_console_drivers() should be fine as well. console_unlock() big printing loop is covered by printk_safe, need to protect console_cont_flush()->call_console_drivers(). so printk "direct path" seems to be safe now: printk -> .. -> console_unlock() -> call_console_drivers() -> serial_console_write() anything that is "indirect" is not covered in this patch set. -ss