linux-kernel - Re: [PATCH] mm: don't warn about allocations which stall for too long

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: <20171101113336.19758220@gandalf.local.home>
Date:   Wed, 1 Nov 2017 11:33:36 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.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>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        "yuwang.yuwang" <yuwang.yuwang@...baba-inc.com>
Subject: Re: [PATCH] mm: don't warn about allocations which stall for too
 long

On Wed, 1 Nov 2017 09:30:05 +0100
Vlastimil Babka <vbabka@...e.cz> wrote:

> 
> But still, it seems to me that the scheme only works as long as there
> are printk()'s coming with some reasonable frequency. There's still a
> corner case when a storm of printk()'s can come that will fill the ring
> buffers, and while during the storm the printing will be distributed
> between CPUs nicely, the last unfortunate CPU after the storm subsides
> will be left with a large accumulated buffer to print, and there will be
> no waiters to take over if there are no more printk()'s coming. What
> then, should it detect such situation and defer the flushing?

No!

If such a case happened, that means the system is doing something
really stupid.

Btw, each printk that takes over, does one message, so the last one to
take over, shouldn't have a full buffer anyway.

But still, if you have such a hypothetical situation, the system should
just crash. The printk is still bounded by the length of the buffer.
Although it is slow, it will finish. Which is not the case with the
current situation. And the current situation (as which this patch
demonstrates) does happen today and is not hypothetical.

-- Steve