Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks
From: Sergey Senozhatsky <hidden>
Date: 2018-06-28 02:55:24
Also in:
lkml
From: Sergey Senozhatsky <hidden>
Date: 2018-06-28 02:55:24
Also in:
lkml
On (06/20/18 12:38), Linus Torvalds wrote:
On Wed, Jun 20, 2018 at 11:50 AM Sergey Senozhatsky [off-list ref] wrote:quoted
It's not UART on its own that immediately calls into printk(), that would be trivial to fix, it's all those subsystems that serial console driver can call into.We already have the whole PRINTK_SAFE_CONTEXT_MASK model that only adds it to a secondary buffer if you get recursion. Why isn't that triggering? That's the whole point of it.
Linus, Alan, Steven, are you on board with the patch set? What shall I do to improve it? PRINTK_SAFE_CONTEXT_MASK is what we answer nowadays when someone says "printk causes deadlocks". We really can't remove all printk-s that can cause uart->...->printk->uart recursion, and the only other option is to use spin_trylock on uart_port->lock in every driver and discard con->write() if we see that we have re-entered uart. I'd rather use per-CPU printk_safe buffer in this case. -ss