linux-kernel - Re: [PATCH] panic: call hardlockup_detector_perf

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: <aKSRzbUvuEkVz-Gk@pathway.suse.cz>
Date: Tue, 19 Aug 2025 17:01:33 +0200
From: Petr Mladek <pmladek@...e.com>
To: Wang Jinchao <wangjinchao600@...il.com>
Cc: John Ogness <john.ogness@...utronix.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Joel Granados <joel.granados@...nel.org>,
	Dave Jiang <dave.jiang@...el.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Sravan Kumar Gundu <sravankumarlpu@...il.com>,
	Ryo Takakura <takakura@...inux.co.jp>, linux-kernel@...r.kernel.org,
	Wei Liu <wei.liu@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH] panic: call hardlockup_detector_perf_stop in panic

On Wed 2025-07-30 11:06:33, Wang Jinchao wrote:
> When a panic happens, it blocks the cpu, which may
> trigger the hardlockup detector if some dump is slow.
> So call hardlockup_detector_perf_stop() to disable
> hardlockup dector.

Could you please provide more details, especially the log showing
the problem?

I wonder if this is similar to
https://lore.kernel.org/all/SN6PR02MB4157A4C5E8CB219A75263A17D46DA@SN6PR02MB4157.namprd02.prod.outlook.com/

There was a problem that a non-panic CPU might get stuck in
pl011_console_write_thread() or any other con->write_thread()
callback because nbcon_reacquire_nobuf(wctxt) ended in an infinite
loop.

It was a real lockup. It has got recently fixed in 6.17-rc1 by
the commit 571c1ea91a73db56bd94 ("printk: nbcon: Allow reacquire
during panic"), see
https://patch.msgid.link/20250606185549.900611-1-john.ogness@linutronix.de
It is possible that it fixed your problem as well.

That said, it might make sense to disable the hardlockup
detector during panic. But I do not like the proposed way,
see below.

> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -339,6 +339,7 @@ void panic(const char *fmt, ...)
>  	 */
>  	local_irq_disable();
>  	preempt_disable_notrace();
> +	hardlockup_detector_perf_stop();

I see the following in kernel/watchdog_perf.c:

/**
 * hardlockup_detector_perf_stop - Globally stop watchdog events
 *
 * Special interface for x86 to handle the perf HT bug.
 */
void __init hardlockup_detector_perf_stop(void)
{
[...]
	lockdep_assert_cpus_held();
[...]
}

1. It is suspicious to see an x86-specific "hacky" function called in
   the generic panic().

   Is this safe?
   What about other hardlockup detectors?

2. I expect that lockdep_assert_cpus_held() would complain
   when CONFIG_LOCKDEP was enabled.

Anyway, it does not look safe. panic() might be called in any context,
including NMI, and I see:

 + hardlockup_detector_perf_stop()
   + perf_event_disable()
     + perf_event_ctx_lock()
       + mutex_lock_nested()

This might cause deadlock when called in NMI, definitely.

Alternative:

A conservative approach would be to update watchdog_hardlockup_check()
so that it does nothing when panic_in_progress() returns true. It
would even work for both hardlockup detectors implementation.

Best Regards,
Petr