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
