All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: sean@ashe.io, akpm@linux-foundation.org,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	joel.granados@kernel.org, pmladek@suse.com, mhiramat@kernel.org
Subject: Re: [v5 PATCH 1/2] hung_task: Introduce helper for hung task warning
Date: Thu, 1 Jan 2026 17:49:59 +0800	[thread overview]
Message-ID: <8a82158f-370a-4c6d-b7f8-71f80aa3e3d2@linux.dev> (raw)
In-Reply-To: <20251231004125.2380105-2-atomlin@atomlin.com>



On 2025/12/31 08:41, Aaron Tomlin wrote:
> Consolidate the multi-line console output block for reporting a hung
> task into a new helper function, hung_task_diagnostics(). This improves
> readability in the main check_hung_task() loop and makes the diagnostic
> output structure easier to maintain and update in the future.
> 
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> ---
>   kernel/hung_task.c | 33 +++++++++++++++++++++++----------
>   1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index d2254c91450b..00c3296fd692 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -223,6 +223,28 @@ static inline void debug_show_blocker(struct task_struct *task, unsigned long ti
>   }
>   #endif
>   
> +/**
> + * hung_task_diagnostics - Print structured diagnostic info for a hung task.
> + * @t: Pointer to the detected hung task.
> + *
> + * This function consolidates the printing of core diagnostic information
> + * for a task found to be blocked.
> + */
> +static inline void hung_task_diagnostics(struct task_struct *t)
> +{
> +	unsigned long blocked_secs = (jiffies - t->last_switch_time) / HZ;
> +
> +	pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
> +	       t->comm, t->pid, blocked_secs);
> +	pr_err("      %s %s %.*s\n",
> +	       print_tainted(), init_utsname()->release,
> +	       (int)strcspn(init_utsname()->version, " "),
> +	       init_utsname()->version);
> +	if (t->flags & PF_POSTCOREDUMP)
> +		pr_err("      Blocked by coredump.\n");
> +	pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n");
> +}
> +
>   static void check_hung_task(struct task_struct *t, unsigned long timeout,
>   		unsigned long prev_detect_count)
>   {
> @@ -252,16 +274,7 @@ static void check_hung_task(struct task_struct *t, unsigned long timeout,
>   	if (sysctl_hung_task_warnings || hung_task_call_panic) {
>   		if (sysctl_hung_task_warnings > 0)
>   			sysctl_hung_task_warnings--;
> -		pr_err("INFO: task %s:%d blocked for more than %ld seconds.\n",
> -		       t->comm, t->pid, (jiffies - t->last_switch_time) / HZ);
> -		pr_err("      %s %s %.*s\n",
> -			print_tainted(), init_utsname()->release,
> -			(int)strcspn(init_utsname()->version, " "),
> -			init_utsname()->version);
> -		if (t->flags & PF_POSTCOREDUMP)
> -			pr_err("      Blocked by coredump.\n");
> -		pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
> -			" disables this message.\n");
> +		hung_task_diagnostics(t);

I am wondering whether we should leave that code as-is to
avoid unnecessary churn ...

That code was not particularly complex or duplicated :)

>   		sched_show_task(t);
>   		debug_show_blocker(t, timeout);
>   


  reply	other threads:[~2026-01-01  9:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-31  0:41 [v5 PATCH 0/2] hung_task: Provide runtime reset interface for hung task detector Aaron Tomlin
2025-12-31  0:41 ` [v5 PATCH 1/2] hung_task: Introduce helper for hung task warning Aaron Tomlin
2026-01-01  9:49   ` Lance Yang [this message]
2026-01-01 19:28     ` Aaron Tomlin
2026-01-02  3:40       ` Lance Yang
2026-01-02 19:02         ` Aaron Tomlin
2025-12-31  0:41 ` [v5 PATCH 2/2] hung_task: Enable runtime reset of hung_task_detect_count Aaron Tomlin
2026-01-01  9:46   ` Lance Yang
2026-01-01 23:14   ` Joel Granados
2026-01-02  1:24     ` Aaron Tomlin
2026-01-05 10:53       ` Joel Granados
2026-01-05 14:42         ` Aaron Tomlin
2026-01-06 11:36           ` Joel Granados
2026-01-07  1:49             ` Aaron Tomlin
2026-01-06 11:51   ` Joel Granados
2026-01-07  3:37     ` Aaron Tomlin
2026-01-08 14:41   ` Petr Mladek
2026-01-09 13:50     ` Lance Yang
2026-01-12 13:13       ` Petr Mladek
2026-01-12 14:43         ` Lance Yang
2026-01-15  2:20           ` Aaron Tomlin
2026-01-10 15:55     ` Aaron Tomlin

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=8a82158f-370a-4c6d-b7f8-71f80aa3e3d2@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=atomlin@atomlin.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel.granados@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=pmladek@suse.com \
    --cc=sean@ashe.io \
    /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.