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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200710091137.GN4751@alley>
Date:   Fri, 10 Jul 2020 11:11:37 +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 Thu 2020-07-09 09:09:31, John Ogness wrote:
> On 2020-07-08, Petr Mladek <pmladek@...e.com> wrote:
> > OK, I think that we are ready to try this in linux-next.
> > I am going to push it there via printk/linux.git.
> >
> > [...]
> > 
> > Of course, there are still many potential problems. The following comes
> > to my mind:
> >
> > [...]
> >
> >    + Debugging tools accessing the buffer directly would need to
> >      understand the new structure. Fortunately John provided
> >      patches for the most prominent ones.
> 
> The next series in the printk-rework (move LOG_CONT handling from
> writers to readers) makes some further changes that, while not
> incompatible, could affect the output of existing tools. It may be a
> good idea to let the new ringbuffer sit in linux-next until the next
> series has been discussed/reviewed/merged. After the next series,
> everything will be in place (with regard to userspace tools) to finish
> the rework.

I know that it might be premature question. But I wonder what kind
of changes are expected because of the continuous lines.

Do you expect some changes in the ring buffer structures so that
the debugging tools would need yet another update to actually
access the data?

Or do you expect backward compatible changes that would allow
to pass related parts of the continuous lines via syslog/dev_kmsg
interface and join them later in userspace?

IMHO, it would make sense to wait only when the structures need
some modification. Concatenating related parts on the userspace
side will need to stay optional anyway.

As I say, this might be premature question. I just do not want
to unnecessary delay mainlining the current state. It would get
much wider testing there. And it is great when the changes might
be done in "small" steps.

Best Regards,
Petr