From: Lance Yang <lance.yang@linux.dev>
To: Feng Tang <feng.tang@linux.alibaba.com>
Cc: Petr Mladek <pmladek@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Lance Yang <ioworker0@gmail.com>,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
paulmck@kernel.org, lirongqing@baidu.com, leonylgao@tencent.com
Subject: Re: [PATCH v2 2/4] hung_task: Add hung_task_sys_info sysctl to dump sys info on task-hung
Date: Sun, 16 Nov 2025 15:58:32 +0800 [thread overview]
Message-ID: <d0577123-59c8-438e-b646-27e70795c17d@linux.dev> (raw)
In-Reply-To: <20251113111039.22701-3-feng.tang@linux.alibaba.com>
On 2025/11/13 19:10, Feng Tang wrote:
> When task-hung happens, developers may need different kinds of system
> information (call-stacks, memory info, locks, etc.) to help debugging.
>
> Add 'hung_task_sys_info' sysctl knob to take human readable string like
> "tasks,mem,timers,locks,ftrace,...", and when task-hung happens, all
> requested information will be dumped. (refer kernel/sys_info.c for more
> details).
>
> Meanwhile, the newly introduced sys_info() call is used to unify some
> existing info-dumping knobs.
>
> Suggested-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
> ---
> Documentation/admin-guide/sysctl/kernel.rst | 5 ++
> kernel/hung_task.c | 62 +++++++++++++--------
> 2 files changed, 43 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
> index a397eeccaea7..45b4408dad31 100644
> --- a/Documentation/admin-guide/sysctl/kernel.rst
> +++ b/Documentation/admin-guide/sysctl/kernel.rst
[...]
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index 5ac0e66a1361..5b3a7785d3a2 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -24,6 +24,7 @@
> #include <linux/sched/sysctl.h>
> #include <linux/hung_task.h>
> #include <linux/rwsem.h>
> +#include <linux/sys_info.h>
>
> #include <trace/events/sched.h>
>
> @@ -59,12 +60,17 @@ static unsigned long __read_mostly sysctl_hung_task_check_interval_secs;
> static int __read_mostly sysctl_hung_task_warnings = 10;
>
> static int __read_mostly did_panic;
> -static bool hung_task_show_lock;
> static bool hung_task_call_panic;
> -static bool hung_task_show_all_bt;
>
> static struct task_struct *watchdog_task;
>
> +/*
> + * A bitmask to control what kinds of system info to be printed when
> + * a hung task is detected, it could be task, memory, lock etc. Refer
> + * include/linux/sys_info.h for detailed bit definition.
> + */
> +static unsigned long hung_task_si_mask;
> +
> #ifdef CONFIG_SMP
> /*
> * Should we dump all CPUs backtraces in a hung task event?
> @@ -217,11 +223,8 @@ static inline void debug_show_blocker(struct task_struct *task, unsigned long ti
> }
> #endif
>
> -static void check_hung_task(struct task_struct *t, unsigned long timeout,
> - unsigned long prev_detect_count)
> +static void check_hung_task(struct task_struct *t, unsigned long timeout)
> {
> - unsigned long total_hung_task;
> -
> if (!task_is_hung(t, timeout))
> return;
>
> @@ -231,20 +234,13 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout,
> */
> sysctl_hung_task_detect_count++;
>
> - total_hung_task = sysctl_hung_task_detect_count - prev_detect_count;
> trace_sched_process_hang(t);
>
> - if (sysctl_hung_task_panic && total_hung_task >= sysctl_hung_task_panic) {
> - console_verbose();
> - hung_task_show_lock = true;
> - hung_task_call_panic = true;
> - }
> -
> /*
> * Ok, the task did not get scheduled for more than 2 minutes,
> * complain:
> */
> - if (sysctl_hung_task_warnings || hung_task_call_panic) {
> + if (sysctl_hung_task_warnings) {
It seems like the behavior changes when sysctl_hung_task_warnings is
0 but a panic is about to be triggered ...
Looking at the history:
1) Commit ("hung_task: ignore hung_task_warnings when hung_task_panic
is enabled")[1] ensured that hung task information is always dumped
when a panic is configured, even if the warning counter is exhausted.
2) Later, commit ("hung_task: panic when there are more than N hung
tasks at the same time")[2] refined the logic to trigger a panic based
on the number of hung tasks found in a single scan.
To stay consistent with the established behavior, I think we should
continue to dump the information for hung tasks as long as
sysctl_hung_task_panic is enabled :)
[1] https://lore.kernel.org/all/20240613033159.3446265-1-leonylgao@gmail.com
[2] https://lore.kernel.org/all/20251015063615.2632-1-lirongqing@baidu.com
[...]
Cheers,
Lance
next prev parent reply other threads:[~2025-11-16 7:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 11:10 [PATCH v2 0/4] Enable hung_task and lockup cases to dump system info on demand Feng Tang
2025-11-13 11:10 ` [PATCH v2 1/4] docs: panic: correct some sys_ifo names in sysctl doc Feng Tang
2025-11-13 11:10 ` [PATCH v2 2/4] hung_task: Add hung_task_sys_info sysctl to dump sys info on task-hung Feng Tang
2025-11-14 15:36 ` Petr Mladek
2025-11-16 7:16 ` Feng Tang
2025-11-16 7:58 ` Lance Yang [this message]
2025-11-16 9:11 ` Feng Tang
2025-11-16 13:22 ` Lance Yang
2025-11-16 14:13 ` Feng Tang
2025-11-17 17:53 ` Andrew Morton
2025-11-18 2:26 ` Feng Tang
2025-11-18 6:06 ` Lance Yang
2025-11-18 15:20 ` Petr Mladek
2025-11-18 17:57 ` Lance Yang
2025-11-19 12:31 ` Petr Mladek
2025-11-13 11:10 ` [PATCH v2 3/4] watchdog: add sys_info sysctls to dump sys info on system lockup Feng Tang
2025-11-14 15:44 ` Petr Mladek
2025-11-13 11:10 ` [PATCH v2 4/4] sys_info: add a default kernel sys_info mask Feng Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0577123-59c8-438e-b646-27e70795c17d@linux.dev \
--to=lance.yang@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=feng.tang@linux.alibaba.com \
--cc=ioworker0@gmail.com \
--cc=leonylgao@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.