linux-kernel - Re: [GIT PULL] printk for 6.11

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]

Message-ID: <20240724124743.GC13387@noisy.programming.kicks-ass.net>
Date: Wed, 24 Jul 2024 14:47:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	John Ogness <john.ogness@...utronix.de>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Thomas Gleixner <tglx@...utronix.de>, Jan Kara <jack@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] printk for 6.11

On Wed, Jul 24, 2024 at 10:42:11AM +0200, Petr Mladek wrote:
> On Tue 2024-07-23 14:07:12, Linus Torvalds wrote:
> > On Tue, 23 Jul 2024 at 13:41, John Ogness <john.ogness@...utronix.de> wrote:
> > >
> > > Petr's pull request provides the functionality for a CPU to call
> > > printk() during emergencies so that each line only goes into the
> > > buffer. We also include a function to perform the flush at any time. As
> > > the series is implemented now, that flush happens after the warning is
> > > completely stored into the buffer. In cases where there is lots of data
> > > in the warning (such as in RCU stalls or lockdep splats), the flush
> > > happens after significant parts of the warning.
> > 
> > I really think the flushing needs to be *way* more aggressive for any
> > oops. The "flush at end" is not even remotely sane.
> > 
> > Some amount of buffering can make sense, eg when printing out the
> > regular register state over a few lines, there certainly shouldn't be
> > anything there that can cause problems.
> 
> Yes, this was the intention. I have missed the code path calling
> the notifiers. The Oops/die code is more complicated.
> 
> Otherwise, nbcon_cpu_emergency_enter()/exit() is
> used only around code printing various well defined debug
> reports, like WARN(), lockdep, or RCU stall.
> 
> Note that the buffering is only in the emergency sections.
> The messages are flushed directly after reaching panic().
> 
> Just to be sure. The buffering is _not_ there to solve cosmetic
> problems. It should allow storing important information before
> trying to flush it to consoles. It is because the flushing to consoles
> is slow, might trigger softlockups and even cause system to die.

So.. I've complained about this emergency buffering before. At the very
least the atomic consoles should never buffer and immediately print
everything. Per their definition they always work.

Slow is not a consideration. You might never reach the end of the
section, anything you can get before the machine dies is a win.