Messages in this thread | | | Date | Thu, 28 Sep 2017 18:17:30 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 0/3] printk: Add force_early_printk boot param |
| |
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)
| |