On 2024-05-23 23:55:37 [+0800], xu.xin16@xxxxxxxxxx wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 7f27cfee283e..faab85dd4439 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3735,6 +3735,14 @@ bool pr_flush(int timeout_ms, bool reset_on_progress)
> diff = 0;
>
> for_each_console(con) {
> + /*
> + * When we're in the unpreemptible context on the same cpu
> + * with which the thread of console locates on, we should
> + * ignore this console, because it's a vain.
> + */
> + if (!preemptible() && con->thread &&
> + task_cpu(con->thread) == smp_processor_id())
> + continue;
> if (!(con->flags & CON_ENABLED))
> continue;
> printk_seq = read_console_seq(con);
This does not apply.
There is `may_sleep' set earlier.
There is no console_lock() around for each…
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).
This is a delay of max 1 sec during bug() and panic(). Not sure how
"critical" this is…
Sebastian
