linux-kernel - Re: [PATCH 9/9] watchdog: skip checks when panic is in progress

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: <aKXnOTq9ZYeVYqH5@yury>
Date: Wed, 20 Aug 2025 11:18:17 -0400
From: Yury Norov <yury.norov@...il.com>
To: Jinchao Wang <wangjinchao600@...il.com>
Cc: pmladek@...e.com, akpm@...ux-foundation.org,
	Douglas Anderson <dianders@...omium.org>,
	Ingo Molnar <mingo@...nel.org>, Li Huafei <lihuafei1@...wei.com>,
	Yicong Yang <yangyicong@...ilicon.com>,
	Thorsten Blum <thorsten.blum@...ux.dev>,
	linux-kernel@...r.kernel.org, feng.tang@...ux.alibaba.com,
	joel.granados@...nel.org, john.ogness@...utronix.de,
	namcao@...utronix.de, sravankumarlpu@...il.com,
	Will Deacon <will@...nel.org>
Subject: Re: [PATCH 9/9] watchdog: skip checks when panic is in progress

On Wed, Aug 20, 2025 at 05:14:54PM +0800, Jinchao Wang wrote:
> Both watchdog_buddy_check_hardlockup() and
> watchdog_overflow_callback() may trigger
> during a panic. This can lead to recursive
> panic handling.
> 
> Add panic_in_progress() checks so watchdog
> activity is skipped once a panic has begun.
> 
> This prevents recursive panic and keeps the
> panic path more reliable.
> 
> Signed-off-by: Jinchao Wang <wangjinchao600@...il.com>
> ---
>  kernel/watchdog_buddy.c | 5 +++++
>  kernel/watchdog_perf.c  | 3 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/kernel/watchdog_buddy.c b/kernel/watchdog_buddy.c
> index ee754d767c21..79a85623028c 100644
> --- a/kernel/watchdog_buddy.c
> +++ b/kernel/watchdog_buddy.c
> @@ -93,6 +93,11 @@ void watchdog_buddy_check_hardlockup(int hrtimer_interrupts)
>  	 */
>  	if (hrtimer_interrupts % 3 != 0)
>  		return;
> +	/*
> +	 * pass the buddy check if a panic is in process
> +	 */
> +	if (panic_in_progress())
> +		return;
>  
>  	/* check for a hardlockup on the next CPU */
>  	next_cpu = watchdog_next_cpu(smp_processor_id());
> diff --git a/kernel/watchdog_perf.c b/kernel/watchdog_perf.c
> index 9c58f5b4381d..7641de750ca5 100644
> --- a/kernel/watchdog_perf.c
> +++ b/kernel/watchdog_perf.c
> @@ -12,6 +12,7 @@
>  
>  #define pr_fmt(fmt) "NMI watchdog: " fmt
>  
> +#include <linux/panic.h>
>  #include <linux/nmi.h>
>  #include <linux/atomic.h>
>  #include <linux/module.h>
> @@ -110,6 +111,8 @@ static void watchdog_overflow_callback(struct perf_event *event,
>  
>  	if (!watchdog_check_timestamp())
>  		return;
> +	if (panic_in_progress())
> +		return;

It looks like watchdog_check_timestamp() does some real work, like
updates last_timestamp and so on. Under the panic condition all this
may be unreliable, right?

Maybe it's worth to make panic_in_progress() the first check in the
chain?

With that,

Reviewed-by: Yury Norov (NVIDIA) <yury.norov@...il.com>

>  
>  	watchdog_hardlockup_check(smp_processor_id(), regs);
>  }
> -- 
> 2.43.0