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

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, 3 Aug 2022 09:08:07 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        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>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] printk for 5.20

On Wed, Aug 3, 2022 at 8:43 AM Petr Mladek <pmladek@...e.com> wrote:
>
> On Tue 2022-08-02 20:19:34, Linus Torvalds wrote:
> > And printing messages to a console is not some "oh, we'll just stop
> > doing that because you asked for PREEMPT_RT".
>
> My thinking was that PREEMPT_RT was used only by some rather small
> community that was very well aware of the upstream status. I kind of
> though that this was their choice.

Oh, I agree that it probably is a pretty small community.

And I also think that people who are really into RT are basically
always going to have extra patches anyway - I think the bulk of the
core stuff has made it upstream, but not *all* has made it.

And the "real RT" people tend to also have long lead times - it's not
just about "we need guaranteed latency", it also tends to be about
"our hardware is special and stays around for years" too - and likely
wouldn't ever really use upstream kernels directly anyway.

In fact, I don't think anybody can currently even enable PREEMPT_RT in
an upstream kernel anyway without extra patches. Much of the RT
infrastructure has been merged, but some of the grottier parts are
literally just "to make it easier to maintain the real external
patch".

So I agree with you that in reality it probably wouldn't really affect
very many people, if any.

I suspect the most immediate effect would literally be people who want
to experiment with it, "just because".

Not the serious RT users who probably have special hardware anyway and
are likely to also have special debug interfaces (exactly _because_
they have special latency concerns).

So that's why I'd suspect that the actual effect would be on people
who just want to tinker with it, and download the necessary RT patches
and set up some data acquisition station for their own use or
whatever.

But thinking some more about it, even the "serious RT" people almost
certainly don't really want some kind of static "disable it all". Not
even if it was a separate Kconfig question like I suggested.

You'd most likely want it to be dynamic, because things like "log to
console" is different at bootup when the system hasn't started yet -
you can't really have realtime response when your hardware hasn't even
initialized yet - and when things are actually running.

So I think even then you really just want a "turn off console logging"
dynamic flag, not a Kconfig option.

Which I think we already have, in the form of log levels. No?

          Linus