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

[Sebastian Andrzej Siewior]

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