From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDBC33BB57 for ; Tue, 3 Feb 2026 03:05:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.186 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770087938; cv=none; b=UkvCs/yh3D7S8hcjd691l5t8ppoB/kZguFVFXuK3zmYqJ2yJPnkpmqCqpRHaJrbXTtKOUJ4rgqqwuoJ9BJ8APwF5veoShVpsjCvH9J9gJFPOC/4R7vF8uMQDJ7hOgwSw+vOmorFU4gIxohR66R19od64wXhaqO4C+4k/BfUGO3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770087938; c=relaxed/simple; bh=4E5Bn5Bvc+r7HnCWZ33uiRjZ0atQEirDSV+AvkaejZI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NAb8luUvsKfkXqAH34FB39PH449g9mthTCX8oo3vBivNZbrlB0SodCsP6142psGsqUTVAbXop6TnMgPBCM3sd06HeMe2BoFLtSkfF1UN06dbf3DHoJ88O+6rEPNpcdoO2HcXcKUCO4AGvHHiW5fu1YnUWDZwIKrEKlW0z0ZCfRY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=L1V0A/QG; arc=none smtp.client-ip=95.215.58.186 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="L1V0A/QG" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770087934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f0cIsg8nfLgD/tG8p+78kjpMiTNBG0UIRAVokcCGMsQ=; b=L1V0A/QGKeO6rP21HW0AQRvZuwz9P7YkQj4aGVPk6X4GxfFUHwMSkSk3eOHH5FXCqEJnhz byF3RnBC5lybTq1Fjo6UoAd2NneAtr+nWkbC2E2AZqePAFk/zT/WiCVLm/YX6ggX+uE0HZ A6mF1MntLUhtfcEV2KPP4JPQUMY/bgs= Date: Tue, 3 Feb 2026 11:05:24 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [v7 PATCH 1/2] hung_task: Refactor detection logic and atomicise detection count Content-Language: en-US To: Aaron Tomlin Cc: neelx@suse.com, sean@ashe.io, akpm@linux-foundation.org, mproche@gmail.com, chjohnst@gmail.com, nick.lange@gmail.com, linux-kernel@vger.kernel.org, mhiramat@kernel.org, joel.granados@kernel.org, pmladek@suse.com, gregkh@linuxfoundation.org References: <20260125135848.3356585-1-atomlin@atomlin.com> <20260125135848.3356585-2-atomlin@atomlin.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20260125135848.3356585-2-atomlin@atomlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/1/25 21:58, Aaron Tomlin wrote: > The check_hung_task() function currently conflates two distinct > responsibilities: validating whether a task is hung and handling the > subsequent reporting (printing warnings, triggering panics, or > tracepoints). > > This patch refactors the logic by introducing hung_task_info(), a > function dedicated solely to reporting. The actual detection check, > task_is_hung(), is hoisted into the primary loop within > check_hung_uninterruptible_tasks(). This separation clearly decouples > the mechanism of detection from the policy of reporting. > > Furthermore, to facilitate future support for concurrent hung task > detection, the global sysctl_hung_task_detect_count variable is > converted from unsigned long to atomic_long_t. Consequently, the > counting logic is updated to accumulate the number of hung tasks locally > (this_round_count) during the iteration. The global counter is then > updated atomically via atomic_long_cmpxchg_relaxed() once the loop > concludes, rather than incrementally during the scan. > > These changes are strictly preparatory and introduce no functional > change to the system's runtime behaviour. > > Signed-off-by: Aaron Tomlin > --- > kernel/hung_task.c | 58 ++++++++++++++++++++++++++-------------------- > 1 file changed, 33 insertions(+), 25 deletions(-) > > diff --git a/kernel/hung_task.c b/kernel/hung_task.c > index d2254c91450b..df10830ed9ef 100644 > --- a/kernel/hung_task.c > +++ b/kernel/hung_task.c > @@ -36,7 +36,7 @@ static int __read_mostly sysctl_hung_task_check_count = PID_MAX_LIMIT; > /* > * Total number of tasks detected as hung since boot: > */ > -static unsigned long __read_mostly sysctl_hung_task_detect_count; > +static atomic_long_t sysctl_hung_task_detect_count = ATOMIC_LONG_INIT(0); > > /* > * Limit number of tasks checked in a batch. > @@ -223,31 +223,29 @@ 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_info - Print diagnostic details for a hung task > + * @t: Pointer to the detected hung task. > + * @timeout: Timeout threshold for detecting hung tasks > + * @this_round_count: Count of hung tasks detected in the current iteration > + * > + * Print structured information about the specified hung task, if warnings > + * are enabled or if the panic batch threshold is exceeded. > + */ > +static void hung_task_info(struct task_struct *t, unsigned long timeout, > + unsigned long this_round_count) > { > - unsigned long total_hung_task; > - > - if (!task_is_hung(t, timeout)) > - return; > - > - /* > - * This counter tracks the total number of tasks detected as hung > - * since boot. > - */ > - sysctl_hung_task_detect_count++; Previously, the global detect count updated immediately when a hung task was found. BUT now, it only updates after the full scan finishes ... Ideally, the count should update as soon as possible, so that userspace can react in time :) For example, by migrating critical containers away from the node before the situation gets worse - something we already do. Cheers, Lance