linux-kernel - Re: [PATCH 5.10-rt] printk: ignore that console preempted by irq/softirq

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: Tue, 28 May 2024 17:29:33 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: xu xin <xu.xin.sc@...il.com>
Cc: xu.xin16@....com.cn, john.ogness@...utronix.de,
	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
	liu.chun2@....com.cn, rostedt@...dmis.org, si.hao@....com.cn,
	yang.yang29@....com.cn, zhang.yunkai@....com.cn
Subject: Re: [PATCH  5.10-rt] printk: ignore that console preempted by
 irq/softirq

On 2024-05-28 06:40:03 [+0000], xu xin wrote:
> > This does not apply.
> > There is `may_sleep' set earlier.
> > 
> > There is no console_lock() around for each…
> > 
> 
> Sorry, I don't get it.
> 
> To clarify it again, this patch aims to solve the useless waiting of pr_flush
> when the console is preempted by the current irq/softirq. This has nothing to
> do with might_sleep().

There is a `may_sleep` variable set earlier. Couldn't that be re-used?

> > The other question is which kernel started enforcing might_sleep() for
> > pr_flush(). This should be applied to all kernel or none so we don't
> > have random behaviour across kernels (5.4 yes, 5.10 no, 5.15 yes).
> >
> 
> Sorry, my understanding is that pr_flush didn't start enforcing might_sleep().
> This patch can apply to 5.10 and 5.15 where the problem exist.

Starting with v6.1-RT there is a might_sleep() at the beginning of
pr_flush(). This means that atomic context can not be used anymore.
Therefore is patch needs only to be applied to 5.10 and 5.15 as you
said. I just didn't see the information the following kernels (>=6.1)
already had that might_sleep() check and the previous (<5.4) lack
pr_flush().

> > This is a delay of max 1 sec during bug() and panic(). Not sure how
> > "critical" this is…
> 
> In some industrial control scenarios, bugs and warnings containning a
> pr_flush delay of 1 sec is very critical to the upper services.
> 
> Especiall for watchdog timeout(< 2s), just WARN can easily lead to system reset,
> which is unacceptible.

Now this would be important piece of information for the changelog in
terms of _why_ we do this.
You don't have an atomic console, do you? Because if this BUG/ WARNING is
printed via the atomic console then it could also raise your 1sec limit.

Sebastian