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]

Message-ID: <YuqroyYLQua8y+L3@gmail.com>
Date:   Wed, 3 Aug 2022 19:08:51 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 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).

As a side note, Red Hat is productizing -rt, and in general lots of systems 
with non-broken hardware will work mostly fine under -rt. For the really 
hairy hard-realtime usecases a lot of verification is done - often as part 
of the project.

With all the 'edge computing' usecases arising & the automotive industry 
getting much more software-intense, I think it's a safe policy to make -rt 
less special & adhere to the same quality and upstream maintenance 
standards as regular Linux distributions.

In a few years PREEMPT_RT won't be all that special anymore, and working 
consoles are very much part of a usable product.

> 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?

Yeah:

  CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
  CONFIG_CONSOLE_LOGLEVEL_QUIET=4

What we could do is to set the default console loglevel really low by on 
PREEMPT_RT - say to 1. Serious crashes would still show up - but random 
console chatter wouldn't.

Thanks,

	Ingo