linux-kernel - Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

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: <20180110190557.GA3460072@devbig577.frc2.facebook.com>
Date:   Wed, 10 Jan 2018 11:05:57 -0800
From:   Tejun Heo <tj@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        akpm@...ux-foundation.org, Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-mm@...ck.org, Cong Wang <xiyou.wangcong@...il.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>, Jan Kara <jack@...e.cz>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        rostedt@...e.goodmis.org, Byungchul Park <byungchul.park@....com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

Hello,

On Wed, Jan 10, 2018 at 07:41:44PM +0100, Peter Zijlstra wrote:
> Typically we (scheduler) have removed printk()s (on boot) when BIGSMP
> folks say it creates boot pain. Much of it is now behind the sched_debug
> parameter, others are compressed.
> 
> I've also seen other people reduce printk()s.
> 
> In general reducing printk() is a good thing, its a low bandwidth
> channel for critical stuff like OOPSen and the like.

Yeah, sure, no disagreement there.  It's just that this is a provision
for when that breaks down.  In the described scenario, it's also not
caused by any particular one printing too many messages.  OOM is just
printing OOM info and packet tx is just printing standard alloc failed
message (and some other following errors).  It's the feedback loop
which kills the machine.

Thanks.

-- 
tejun