linux-kernel - Re: [PATCH printk v2 2/2] printk: Avoid scheduling irq

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: <jvn24vsnd2utypz33k33n3ol3ihh44tcyhcbtjhfxnepuvb7hn@qhcikbtwioyk>
Date: Thu, 13 Nov 2025 11:38:33 -0500
From: Derek Barbosa <debarbos@...hat.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Petr Mladek <pmladek@...e.com>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, 
	Sherry Sun <sherry.sun@....com>, Jacky Bai <ping.bai@....com>, Jon Hunter <jonathanh@...dia.com>, 
	Thierry Reding <thierry.reding@...il.com>, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH printk v2 2/2] printk: Avoid scheduling irq_work on
 suspend

On Thu, Nov 13, 2025 at 05:09:48PM +0106, John Ogness wrote:

> ---
>  @sherry.sun: This patch is essentially the same as v1, but since
>  two WARN_ON_ONCE() were added, I decided not to use your
>  Tested-by. It would be great if you could test again with this
>  series.
> 
>  kernel/printk/internal.h |  8 +++---
>  kernel/printk/nbcon.c    |  7 +++++
>  kernel/printk/printk.c   | 58 +++++++++++++++++++++++++++++-----------
>  3 files changed, 55 insertions(+), 18 deletions(-)
> 
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index 73f315fd97a3e..730d14f6cbc58 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1276,6 +1276,13 @@ void nbcon_kthreads_wake(void)
>  	if (!printk_kthreads_running)
>  		return;
>  
> +	/*
> +	 * It is not allowed to call this function when console irq_work
> +	 * is blocked.
> +	 */
> +	if (WARN_ON_ONCE(console_irqwork_blocked))
> +		return;
> +

> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index dc89239cf1b58..b1c0d35cf3caa 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -462,6 +462,9 @@ bool have_boot_console;
>  /* See printk_legacy_allow_panic_sync() for details. */
>  bool legacy_allow_panic_sync;
>  
> +/* Avoid using irq_work when suspending. */
> +bool console_irqwork_blocked;
> +
>  #ifdef CONFIG_PRINTK
>  DECLARE_WAIT_QUEUE_HEAD(log_wait);
>  static DECLARE_WAIT_QUEUE_HEAD(legacy_wait);
> @@ -2426,7 +2429,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>  
>  	if (ft.legacy_offload)
>  		defer_console_output();
> -	else
> +	else if (!console_irqwork_blocked)
>  		wake_up_klogd();
>  
>  	return printed_len;
> @@ -2730,10 +2733,20 @@ void console_suspend_all(void)
>  {
>  	struct console *con;
>  
> +	if (console_suspend_enabled)
> +		pr_info("Suspending console(s) (use no_console_suspend to debug)\n");
> +
> +	/*
> +	 * Flush any console backlog and then avoid queueing irq_work until
> +	 * console_resume_all(). Until then deferred printing is no longer
> +	 * triggered, NBCON consoles transition to atomic flushing, and
> +	 * any klogd waiters are not triggered.
> +	 */
> +	pr_flush(1000, true);
> +	console_irqwork_blocked = true;
> +

Thanks for this. I have recently have been seeing the same issue with a large-CPU
workstation system in which the serial console been locking up entry/exit of S4
Hibernation sleep state at different intervals.

I am still running tests on the V1 of the series to determine reproducibility,
but I will try to get this version tested in a timely manner as well.

I did, however, test the proto-patch at [0]. The original issue was reproducible
with this patch applied. Avoiding klogd waking in vprintk_emit() and the
addition of the check in nbcon.c (new in this series) opposed to aborting
callers outright seems more airtight.


[0] https://github.com/Linutronix/linux/commit/ae173249d9028ef159fba040bdab260d80dda43f
-- 
Derek <debarbos@...hat.com>