linux-kernel - Re: [RFC][PATCHv2 2/4] printk: move printk

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:   Mon, 22 Oct 2018 16:30:29 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        Daniel Wang <wonderfly@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Jiri Slaby <jslaby@...e.com>,
        Peter Feiner <pfeiner@...gle.com>,
        linux-serial@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        john.ogness@...utronix.de
Subject: Re: [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk
 header

On Wed 2018-10-17 16:00:44, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 12:50:15PM +0200, Petr Mladek wrote:
> > Also note that by deferred printk I mean deferring the console
> > handling! IMHO, there are _no more problems_ with storing
> > the messages into the buffer if we accept that the current
> > very limited use of printk_safe per-cpu buffers is easier
> > than any complicated generic lockless buffer.
> 
> They hide messages. The whole two radically different printk paths is
> also quite horrible.

I agree that having everything in one buffer with unified
and safe access from any context would be a great win.


> And lockless buffers aren't all _that_ complicated, esp. not when
> performance isn't the top priority.
>
> And earlycon is mostly usable, esp. the serial ones. Those, when
> configured, should synchronously print along. The current design
> also makes that difficult.
>
> A wee little like so; typed in a hurry, never been near a compiler.

Thanks a lot for the code. I still need to find time to better
understand it. Anyway, it looks worth considering.

Best Regards,
Petr