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, 10 Jan 2018 10:57:47 -0800
From:   Tejun Heo <tj@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        akpm@...ux-foundation.org, 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>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        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, Steven.

On Wed, Jan 10, 2018 at 01:41:57PM -0500, Steven Rostedt wrote:
> The issue with the solution you want to do with printk is that it can
> break existing printk usages. As Petr said, people want printk to do two
> things. 1 - print out data ASAP, 2 - not lock up the system. The two
> are fighting each other. You care more about 2 where I (and others,
> like Peter Zijlstra and Linus) care more about 1.
> 
> My solution can help with 2 without doing anything to hurt 1.

I'm not really sure why punting to a safe context is necessarily
unacceptable in terms of #1 because there seems to be a pretty wide
gap between printing useful messages synchronously and a system being
caught in printk flush to the point where the system is not
operational at all.

> You are NACKing my solution because it doesn't solve this bug with net
> console. I believe net console should be fixed. You believe that printk
> should have a work around to not let net console type bugs occur. Which
> to me is papering over the real bugs.

As I wrote along with nack, I was more concerned with how this was
pushed forward by saying that actual problems are not real.

As for the netconsole part, sure, that can be one way, but please
consider that the messages could be coming from network drivers, of
which we have many and a lot of them aren't too high quality.  Plus,
netconsole is a separate path and network drivers can easily
malfunction on memory allocation failures.

Again, not a critical problem.  We can decide either way but it'd be
better to be generally safe (if we can do that reasonably), right?

Thanks.

-- 
tejun