linux-kernel - Re: [PATCH v4 0/4] printk: replace ringbuffer

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, 8 Jul 2020 17:20:05 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paul McKenney <paulmck@...nel.org>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/4] printk: replace ringbuffer

On Tue 2020-07-07 17:05:28, John Ogness wrote:
> Hello,
> 
> Here is a v4 for the first series to rework the printk
> subsystem. The v3 is here [0]. This first series
> only replaces the existing ringbuffer implementation. No locking
> is removed. The semantics/behavior of printk are kept the same
> except for a minor optimization that is reverted (patch 3).
> 
> Despite minor changes to the ringbuffer code since v3 (comments,
> function names, very minor refactoring), the ringbuffer logic
> itself has not changed. And, in particular, the memory barriers
> have been exactly preserved from v3. For this reason I deem it
> appropriate to keep Paul's reviewed by tag (patch 2).
> 
> RFC patches for various userspace tools to dump the kernel log
> are available: crash [1], makedumpfile [2], kexec-tools [3].
> 
> Finally, I would like to thank some people/organizations that
> helped with performing ringbuffer stress tests on big or rare
> hardware that I do not have access to:
> 
> - Prarit Bhargava of Red Hat (x86_64, ppc64le power8)
> - Michael Cree of Debian (alpha)
> - Jeff Scheel of OSU Open Source Lab (ppc64le power8 kvm)

OK, I think that we are ready to try this in linux-next.
I am going to push it there via printk/linux.git.

I have a good feeling about the patchset. The great thing is that
the access is still synchronized using logbuf_lock so that we do not
have to deal with races for the moment.

Of course, there are still many potential problems. The following comes
to my mind:

   + Bugs in the algorithm logic or implementation might prevent
     showing any messages on consoles or via syslog or /dev/kmsg.
     We did our best to avoid it.

   + Debugging tools accessing the buffer directly would need to
     understand the new structure. Fortunately John provided
     patches for the most prominent ones.

   + Small devices might complain about less effective use of memory.
     Part of descriptors and dictionaries ring buffers might stay
     unused. But it hopefully could get tuned.


This is basically just a start of the journey. I hope that it will be a
good one.

Best Regards,
Petr