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, linux-kernel@vger.kernel.org, pmladek@suse.com,
	gregkh@linuxfoundation.org, mhiramat@kernel.org,
	akpm@linux-foundation.org, joel.granados@kernel.org
Subject: Re: [v6 PATCH 2/2] hung_task: Enable runtime reset of hung_task_detect_count
Date: Thu, 15 Jan 2026 11:06:16 +0800	[thread overview]
Message-ID: <8c753996-a649-4e43-8b26-cac4780bbcd0@linux.dev> (raw)
In-Reply-To: <20260115023229.3028462-3-atomlin@atomlin.com>



On 2026/1/15 10:32, Aaron Tomlin wrote:
> Currently, the hung_task_detect_count sysctl provides a cumulative count
> of hung tasks since boot. In long-running, high-availability
> environments, this counter may lose its utility if it cannot be reset
> once an incident has been resolved. Furthermore, the previous
> implementation relied upon implicit ordering, which could not strictly
> guarantee that diagnostic metadata published by one CPU was visible to
> the panic logic on another.
> 
> This patch introduces the capability to reset the detection count by
> writing "0" to the hung_task_detect_count sysctl. The proc_handler logic
> has been updated to validate this input and atomically reset the
> counter.
> 
> The synchronisation of sysctl_hung_task_detect_count relies upon a
> transactional model to ensure the integrity of the detection counter
> against concurrent resets from userspace. The application of
> atomic_long_read_acquire() and atomic_long_cmpxchg_release() is correct
> and provides the following guarantees:
> 
>      1. Prevention of Load-Store Reordering via Acquire Semantics By
>         utilising atomic_long_read_acquire() to snapshot the counter
>         before initiating the task traversal, we establish a strict
>         memory barrier. This prevents the compiler or hardware from
>         reordering the initial load to a point later in the scan. Without
>         this "acquire" barrier, a delayed load could potentially read a
>         "0" value resulting from a userspace reset that occurred
>         mid-scan. This would lead to the subsequent cmpxchg succeeding
>         erroneously, thereby overwriting the user's reset with stale
>         increment data.
> 
>      2. Atomicity of the "Commit" Phase via Release Semantics The
>         atomic_long_cmpxchg_release() serves as the transaction's commit
>         point. The "release" barrier ensures that all diagnostic
>         recordings and task-state observations made during the scan are
>         globally visible before the counter is incremented.
> 
>      3. Race Condition Resolution This pairing effectively detects any
>         "out-of-band" reset of the counter. If
>         sysctl_hung_task_detect_count is modified via the procfs
>         interface during the scan, the final cmpxchg will detect the
>         discrepancy between the current value and the "acquire" snapshot.
>         Consequently, the update will fail, ensuring that a reset command
>         from the administrator is prioritised over a scan that may have
>         been invalidated by that very reset.
> 
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> ---
>   Documentation/admin-guide/sysctl/kernel.rst |   3 +-
>   kernel/hung_task.c                          | 109 +++++++++++++-------
>   2 files changed, 75 insertions(+), 37 deletions(-)
> 
> diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
> index 239da22c4e28..68da4235225a 100644
> --- a/Documentation/admin-guide/sysctl/kernel.rst
> +++ b/Documentation/admin-guide/sysctl/kernel.rst
> @@ -418,7 +418,8 @@ hung_task_detect_count
>   ======================
>   
>   Indicates the total number of tasks that have been detected as hung since
> -the system boot.
> +the system boot or since the counter was reset. The counter is zeroed when
> +a value of 0 is written.
>   
>   This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
>   
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index b5ad7a755eb5..2eb9c861bdcc 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -224,24 +224,43 @@ 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)
> +/**
> + * 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 total_hung_task, cur_detect_count;
> -
> -	if (!task_is_hung(t, timeout))
> -		return;
> -
> -	/*
> -	 * This counter tracks the total number of tasks detected as hung
> -	 * since boot.
> -	 */
> -	cur_detect_count = atomic_long_inc_return_relaxed(&sysctl_hung_task_detect_count);
> -	total_hung_task = cur_detect_count - prev_detect_count;
> +	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");
> +}

I see hung_task_diagnostics() is still in this patch. I thought
we'd concluded that[1] the refactoring wasn't really necessary for a
single-use block?

[1] 
https://lore.kernel.org/all/noze3vhqjbsuulvvoaw4h5yeinggpwfslrit5vsd2dllfo4ath@qgmp22hoibgn/

  reply	other threads:[~2026-01-15  3:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-15  2:32 [v6 PATCH 0/2] hung_task: Provide runtime reset interface for hung task detector Aaron Tomlin
2026-01-15  2:32 ` [v6 PATCH 1/2] hung_task: Convert detection count to atomic_long_t Aaron Tomlin
2026-01-15  2:32 ` [v6 PATCH 2/2] hung_task: Enable runtime reset of hung_task_detect_count Aaron Tomlin
2026-01-15  3:06   ` Lance Yang [this message]
2026-01-15 18:24     ` Aaron Tomlin
2026-01-16  2:10       ` Lance Yang
2026-01-15  3:24 ` [v6 PATCH 0/2] hung_task: Provide runtime reset interface for hung task detector Lance Yang
2026-01-15 18:18   ` Aaron Tomlin
2026-01-16  2:22     ` Lance Yang
2026-01-20  9:46       ` Petr Mladek
2026-01-20 11:48         ` Lance Yang
2026-01-23  0:59         ` 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=8c753996-a649-4e43-8b26-cac4780bbcd0@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.