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:   Thu, 11 Jan 2018 12:24:26 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Tejun Heo <tj@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-mm <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>,
        Peter Zijlstra <peterz@...radead.org>, Jan Kara <jack@...e.cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        rostedt@...e.goodmis.org, Byungchul Park <byungchul.park@....com>,
        Pavel Machek <pavel@....cz>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On Thu 2018-01-11 16:36:18, Sergey Senozhatsky wrote:
> Hi Mathieu,
> 
> On (01/10/18 18:40), Mathieu Desnoyers wrote:
> [..]
> > 
> > There appears to be two problems at hand. One is making sure a console
> > buffer owner only flushes a bounded amount of data.
> 
> which, realistically, has quite little to do with the "and thus it
> fixes the lockups". logbuf size is mutable, the number of consoles we
> need to sequentially push the data to is mutable, the watchdog threshold
> is mutable... if combination of first two mutable things produces the
> result which makes the check based on the third mutable thing happy,
> then it's just an accident. my 5 cents.

Yes, there might be situations when Steven's patch is not able to
prevent the softlockup. But there is clear evidence that it will
help in many other situations.

The offload-based solution prevents the softlockup completely.
But there might be situations where the offload does not happen
and people might miss important messages.

And this is my point. Steven's patch is not perfect. But it helps
and it seems that it does not cause regressions. The offload based
solution solves one problem a better way but it might cause
regressions that are being discussed for years.

IMHO, nobody know how much Steven's solution is effective until we
push it into the wild. IMHO, it is safe to be pushed.

You might argue that we already know that Steven's solution will
not be enough. IMHO, the problem here is the term "real life example".

My understanding is that real-life example is a softlockup report
from a system running in production or used for debugging any bug.
So far, Steven's opponents provided only hand made code or
scenarios. The provided code usually produced printk() messages
in a tight loop. In each case, there is not a consensus that they
simulated a real life problem good enough. We might continue
discussing it but basically any discussion is theoretical unless
there are hard data behind it.

I vote to push Steven's patch into the wild and see. I really would
like to give it a chance.

Best Regards,
Petr