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.

This is exactly what I'm doing in my patch set.
PRINTK_SAFE_CONTEXT_MASK so far worked *one* way only: when we start
from printk.c

IOW:

      printk -> printk_safe_mask -> vsprinf -> printk

But we also can have printk-related deadlocks the *other* way
around. For instance:

      uart -> printk -> uart

printk_safe_mask is not triggering there because we don't use
printk_safe in uart / tty yet. And this is what I do in my
patch set - extend printk_safe usage.

The patch set does not add any _new_ locks or locking rules.
It just replaces the existing

		spin_lock(a)
with
		prinkt_safe_enter();
		spin_lock(a)

and
		spin_unlock(a)
with
		spin_unlock(a)
		printk_safe_exit();

and that's it.

So now we use printk_safe mechanism to avoid another bunch of
deadlock scenarious: which don't start from printk, but from
parts of the kernel which printk eventually calls.

	-ss