On Fri 2018-06-29 10:47:03, Sergey Senozhatsky wrote:
On (06/28/18 11:41), Petr Mladek wrote:
A side note: This nesting also handles recursive printk-s for us.
NMI: printk_nmi_enter ftrace_dump printk_nmi_direct_enter vprintk_func spin_lock(logbuf_lock) vprintk_store vsprintf WARN_ON vprintk_func vprintk_nmi
Uff, it seems that the current design is "good" at lest from some points of view.
yep yep
len = vprintk_store(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);raw_spin_unlock(&logbuf_lock);defer_console();return len;- }
So, maybe, something a bit better than defer_console().
I am not super happy with the name either. But wakeup_console(), schedule_console(), or queue_console() looked confusing.
Hmm. defer_console() makes me think that we are dealing with that fbcon=nodefer and deferred console takeover thing here.
So I summon Mr. Rostedt!
Does schedule_console_output() look bad? What about defer_console_output()?
I am fine with both. I slightly prefer defer_console_output() because I have "schedule" associated with deadlocks in this code path (context) ;-)
Best Regards, Petr