Thread (24 messages) 24 messages, 7 authors, 2018-06-28

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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help