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: <CAHk-=wgJrCwOwj4myGgpgyig9dX37hir1S2Xdeg1=kVS-hPzAg@mail.gmail.com>
Date: Wed, 24 Jul 2024 13:33:20 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Petr Mladek <pmladek@...e.com>, 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, 24 Jul 2024 at 05:47, Peter Zijlstra <peterz@...radead.org> wrote:
>
> 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.

Yeah, my personal preference would be some variation of this.

And when I say "some variation of this", I do think that having a
per-console trylock is fine, and buffering *if* the atomic console is
already busy (presumably with an existing oops, but possibly also for
"setup issues" - ie things like "serial line is being configured" or
"VGACON is in the middle of a redraw or console size change
operation".

And yes, before anybody speaks up, that is kind of the approximation
of the current console_trylock() logic. I am aware. And I'm also aware
of how much people have hated it. And I'm not claiming it's perfect.

But I do think that the *typically* important case is "something went
horribly wrong, and the console was *not* busy at the time", and
that's the case where there is no excuse to not just print out ASAP.

And yes, then if some oops happens _while_ the console is busy
(possibly because another oops just happened on another CPU core, and
now *this* CPU also hit it), at that point you go "Ok, trying to print
now would just make things worse".

And a lot of consoles may end up simply having to buffer, ie if you
are using a network console or something, maybe "not buffering is so
painful and involves thousands of random network cards that we
realistically cannot deal with it".

(Same ultimately goes for slow serial lines - there comes a point
where waiting for things to flush just isn't worth it)

So I'm not saying "never buffer". There are very valid reasons to say
"I can't very reasonably print this synchronously".

But I really do think that we should never buffer "by default". And
that's why I kind of hate that whole concept of "oops_begin starts
buffering". It's exactly the kind of "buffer by default" mental model
that I was really hoping we'd never have.

            Linus