[PATCH][v4] hung_task: Panic when there are more than N hung tasks at the same time

Lance Yang lance.yang at linux.dev
Thu Oct 16 16:07:23 AEDT 2025


LGTM. It works as expected, thanks!

On 2025/10/15 14:36, lirongqing wrote:
> From: Li RongQing <lirongqing at baidu.com>

For the commit message, I'd suggest the following for better clarity:

```
The hung_task_panic sysctl is currently a blunt instrument: it's all
or nothing.

Panicking on a single hung task can be an overreaction to a transient
glitch. A more reliable indicator of a systemic problem is when multiple
tasks hang simultaneously.

Extend hung_task_panic to accept an integer threshold, allowing the kernel
to panic only when N hung tasks are detected in a single scan. This
provides finer control to distinguish between isolated incidents and
system-wide failures.

The accepted values are:
- 0: Don't panic (unchanged)
- 1: Panic on the first hung task (unchanged)
- N > 1: Panic after N hung tasks are detected in a single scan

The original behavior is preserved for values 0 and 1, maintaining full
backward compatibility.
```

If you agree, likely no need to resend - Andrew could pick it up
directly when applying :)

> 
> Currently, when 'hung_task_panic' is enabled, the kernel panics
> immediately upon detecting the first hung task. However, some hung
> tasks are transient and allow system recovery, while persistent hangs
> should trigger a panic when accumulating beyond a threshold.
> 
> Extend the 'hung_task_panic' sysctl to accept a threshold value
> specifying the number of hung tasks that must be detected before
> triggering a kernel panic. This provides finer control for environments
> where transient hangs may occur but persistent hangs should be fatal.
> 
> The sysctl now accepts:
> - 0: don't panic (maintains original behavior)
> - 1: panic on first hung task (maintains original behavior)
> - N > 1: panic after N hung tasks are detected in a single scan
> 
> This maintains backward compatibility while providing flexibility for
> different hang scenarios.
> 
> Signed-off-by: Li RongQing <lirongqing at baidu.com>
> Cc: Andrew Jeffery <andrew at codeconstruct.com.au>
> Cc: Anshuman Khandual <anshuman.khandual at arm.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: David Hildenbrand <david at redhat.com>
> Cc: Florian Wesphal <fw at strlen.de>
> Cc: Jakub Kacinski <kuba at kernel.org>
> Cc: Jason A. Donenfeld <jason at zx2c4.com>
> Cc: Joel Granados <joel.granados at kernel.org>
> Cc: Joel Stanley <joel at jms.id.au>
> Cc: Jonathan Corbet <corbet at lwn.net>
> Cc: Kees Cook <kees at kernel.org>
> Cc: Lance Yang <lance.yang at linux.dev>
> Cc: Liam Howlett <liam.howlett at oracle.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> Cc: "Masami Hiramatsu (Google)" <mhiramat at kernel.org>
> Cc: "Paul E . McKenney" <paulmck at kernel.org>
> Cc: Pawan Gupta <pawan.kumar.gupta at linux.intel.com>
> Cc: Petr Mladek <pmladek at suse.com>
> Cc: Phil Auld <pauld at redhat.com>
> Cc: Randy Dunlap <rdunlap at infradead.org>
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: Shuah Khan <shuah at kernel.org>
> Cc: Simon Horman <horms at kernel.org>
> Cc: Stanislav Fomichev <sdf at fomichev.me>
> Cc: Steven Rostedt <rostedt at goodmis.org>
> ---

So:

Reviewed-by: Lance Yang <lance.yang at linux.dev>
Tested-by: Lance Yang <lance.yang at linux.dev>

Cheers,
Lance


More information about the Linux-aspeed mailing list