Re: [PATCH 0/3] printk: Add force_early_printk boot param

[Peter Zijlstra]

On Fri, Sep 29, 2017 at 01:02:30AM +0900, Sergey Senozhatsky wrote:
> but what's up with that scheduler thing I keep hearing about, must be
> something new, can I disable it in kconfig? it seems to be conflicting
> with CONFIG_PRINTK.

Its not new, its been there for a very long time :-)

The problem is that the scheduler has WARN()s in, those tend to tickle
printk(). Printk() on its own has this console semaphore that tends to
want to schedule. Console drivers have things like wakeups, which tend
to not work when you're already holding scheduler locks etc..

Its one big giant mess.. Since you removed that lockdep_off() from
printk() lockdep now sees and complains, which again hits printk(),
recursion FTW!

Similarly, since there's a metric ton of locks all over printk() and
console driver code, printk() doesn't work well from NMI context. And
the taken approach to buffering and then printing later has issues if
there is no later.

Both problems are solved by using early_printk which has lockless
drivers (x86 early_serial_console is the one I use) and avoids all
problems that way.

Its bullet proof console output. Always works. Its been very good to me.

(it of course doesn't help that I work on the scheduler and perf, the
latter of which does lots of cruft in NMI context. So I tend to run into
the very worst possible situations more than most other people)