Thread (44 messages) 44 messages, 7 authors, 2018-12-12

Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header

From: Peter Zijlstra <peterz@infradead.org>
Date: 2018-10-16 12:18:06
Also in: lkml

On Tue, Oct 16, 2018 at 01:40:06PM +0200, Petr Mladek wrote:
On Tue 2018-10-16 09:27:19, Peter Zijlstra wrote:
quoted
Instead of this tinkering around the edges, why don't you make the main
logbuf a lockless ringbuffer and then delegate the actual printing of
that buffer to a kthread, except for earlycon, which can do synchronous
output.
In fact, there is no problem with printk log buffer. This patchset
tries to avoid deadlock caused by console-specific locks
used by console->write() methods.

By other words, we neither need printk_safe or lockless log buffer
to fix this prolem. Instead, we need either printk_deferred context
or lockless consoles.
If you have a lockless buffer and a trailing printk thread, that's
deferred.

And earlycon _should_ be lockless (yes, I know, some suck)

But if you do this deferred nonsense that's currently in printk, then
you risk never seeing the message -- the same problem I have with the
whole printk_safe thing too.

Printing _after_ the fact is horrible for robustness.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help