linux-kernel - Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

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]

Date:   Tue, 19 Dec 2017 10:03:11 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Tejun Heo <tj@...nel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On (12/18/17 12:46), Steven Rostedt wrote:
> On Mon, 18 Dec 2017 15:13:53 +0100
> Petr Mladek <pmladek@...e.com> wrote:
> 
> > One question is if we really want to rely on offloading in
> > this case. What if this is printed to debug some stalled
> > system.
> 
> Correct, and this is what I call when debugging hard lockups, and I do
> it from NMI. Which the new NMI code prevents all the data I want to
> print to come out to console.
> 
> I had to create a really huge buffer to print it.
> 
> show_state_filter() is not a normal printk() call. It is used for
> debugging. Not a very good example of issues that happen on production
> systems. If anything, this should be disabled on a production system.
> 
> Let's just add my patch (I'll respin it if it needs it), and send it
> off into the wild. Let's see if there's still reports of issues, and
> then come back to solutions. Because, really, I'm still not convinced
> that there's anything out there that needs much more "fixing" of
> printk().

... do you guys read my emails? which part of the traces I have provided
suggests that there is any improvement?

	-ss