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]

Date:   Wed, 24 Jan 2018 10:46:06 -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, Peter.

On Wed, Jan 24, 2018 at 10:36:07AM +0100, Peter Zijlstra wrote:
> On Wed, Jan 10, 2018 at 09:02:23AM -0800, Tejun Heo wrote:
> > 1. Console is IPMI emulated serial console.  Super slow.  Also
> >    netconsole is in use.
> 
> So my IPMI SoE typically run at 115200 Baud (or higher) and I've not had
> trouble like that (granted I don't typically trigger OOM storms, but
> they do occasionally happen).
> 
> Is your IPMI much slower and not fixable to be faster?

It looks like the latest machines have the baud rate at 57600 and I'm
pretty sure we have a lot of slower ones.  57600 isn't 9600 but is
still slow enough to get into trouble often enough.  There are a huge
number of machines running all sorts of things under heavy load and
trying to rapidly deploy new kernels / features contributes to
encountering bugs and weird corner cases.

UART can run a lot faster and I have no idea why IPMI consoles behave
as if they were connected over mile-long DB9 cables.  Maybe we can
convince hardware people to improve it but, even if that happened
today, we'd still be looking at years of dealing with slower ones, and
IPMI situation here is likely better than what many others are facing.

idk, it's not a particularly difficult problem to solve from kernel
side.  Just need to figure out a better / more robust trade-off.

Thanks.

-- 
tejun