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] [day] [month] [year] [list]

Message-ID: <20200714025626.GD491026@jagdpanzerIV.localdomain>
Date:   Tue, 14 Jul 2020 11:56:26 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>,
        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 (20/07/10 11:58), John Ogness wrote:
> 
> IMHO users of these sequence number interfaces need to see all the
> records individually and reassemble the LOG_CONT messages themselves if
> they want to. I believe that is the only sane path forward. To do this,
> the caller id will no longer be optional to the sequence number output
> since that is vital information to re-assemble the LOG_CONT messages.

Agreed. The caller id thus probably can be extended. Right now it only
tells us either we are in a process context (PID) or in something else.
This works sort of fine (I guess) because deeply nested printouts (printks
from NMI atop of process or irq printks) land in the deferred printk-safe
buffers, but things will change with the new logbuf (and after removal of
the logbuf_lock and per-CPU printk-safe buffers).

	-ss