On (10/16/18 14:04), Sergey Senozhatsky wrote: [..] > - The first entry point is console ->write() callback, which we call > from printk(). A possible deadlock scenario there is: > > CPU0 > <NMI> > spin_lock_irqsave(&port->lock, flags) << deadlock > serial_foo_write() > call_console_drivers() > console_unlock() > console_flush_on_panic() > panic() > <NMI/> > spin_lock_irqsave(&port->lock, flags) > serial_foo_write() > call_console_drivers() > console_unlock() > printk() > ... [..] > - The rest (of entry points) requires a bit different handling. > Let's take a look at the following backtrace: > > CPU0 > <IRQ> > spin_lock_irqsave(&port->lock, flags) << deadlock > serial_foo_write() > call_console_drivers() > console_unlock() > printk() > __queue_work() > tty_flip_buffer_push() > spin_lock_irqsave(&port->lock, flags) > serial_foo_handle_IRQ() > <IRQ/> > > Serial drivers invoke tons of core kernel functions - WQ, MM, etc. All > of which may printk() in various cases. So we can't really just > "remove those printk-s". The simples way to address this seems to be > PRINTK_SAFE_CONTEXT_MASK. serial/UART and printk guys, sorry to bother you, do you hate this idea of removing console_driver->CORE KERNEL->printk->console_driver deadlock path? Or is there any chance we can move forward? -ss
