linux-kernel - Re: printk meeting at LPC

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190918080832.GA37041@jagdpanzerIV>
Date:   Wed, 18 Sep 2019 17:08:32 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>, Paul Turner <pjt@...gle.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Prarit Bhargava <prarit@...hat.com>
Subject: Re: printk meeting at LPC

On (09/18/19 09:33), John Ogness wrote:
> 
> I expect sysrq to be the only valid use of "synchronous state" other
> than oops/panic. Although I suppose PeterZ would like a boot argument to
> always run the consoles in this state.

Yes, there might be more cases when we need sync printk(). Like lockdep
splats, KASAN warnings, PM debugging, etc. Those things sometimes come
right before "truly bad stuff".

> > For instance, tty/sysrq must be able to switch printk emergency
> > on/off.
> 
> The switch/flush _will_ be visible. But not the state. So, for example,
> it won't be possible for some random driver to determine if we are in an
> emergency state. (Well, I don't know if oops_in_progress will really
> disappear. But at least the printk/console stuff will no longer rely on
> it.)
[..]
> Thanks for bringing up that RFC thread again. I haven't looked at it in
> over a year. I will go through it again to see if there is anything I've
> overlooked. Particularly the suspend stuff.

That thread most likely is incomplet and incorrekt in some parts;
shouldn't be taken too seriously, I guess.

	-ss