lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 28 Sep 2017 18:17:30 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     pmladek@...e.com, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, mingo@...nel.org, tglx@...utronix.de
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)

Powered by blists - more mailing lists