linux-kernel - Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

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:   Fri, 15 Dec 2017 10:42:31 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Tejun Heo <tj@...nel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On Fri, 15 Dec 2017 09:31:51 +0100
Petr Mladek <pmladek@...e.com> wrote:

> Do people have issues with the current upstream printk() or
> still even with Steven's patch?
> 
> My current view is that Steven's patch could not make things
> worse. I was afraid of possible deadlock but it seems that I was
> wrong. Other than that the patch should make things just better
> because it allows to pass the work from time to time a safe way.
> 
> Of course, there is a chance that it will pass the work from
> a safe context to atomic one. But there was the same chance that
> the work already started in the atomic context. Therefore statistically
> this should not make things worse.
> 
> This is why I suggest to start with Steven's solution. If people
> would still see problems in the real life then we could think
> about how to fix it. It is quite likely that we would need to add
> offloading to the kthreads in the end but there is a chance...
> 
> In each case, I think that is better to split in into
> two or even more steps than introducing one mega-complex
> change. And given the many-years resistance against offloading
> I tend to start with Steven's approach.

THANK YOU!!!

This is exactly what I'm trying to convey.

> 
> Does this make some sense, please?

It definitely does to me :-)

-- Steve