From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) (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 51EEE26529A for ; Fri, 19 Dec 2025 14:18:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766153923; cv=none; b=nVWtyi1k285OQH3YDy+pWnYvLA6Pc4xPfceoxBTti94KLzNDW01/w0i3zJM4EbFqOXRFZPOgA69BC2/RbgOFKTDWxLSJMmgg9v0Z/vO87A6E5ukbDxhl56fuEQ8OGZQ/W2MwT9MoUaKGOi7SMWTf5gkffF3YloEW+PIrIAdYonI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766153923; c=relaxed/simple; bh=xdovgoVwMUpU9K0cGrbzSZ8P3g/x3f/strZmG93mLPo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=j/hYMOBkZfJrBwyx/PsVNvhiZuBLT0SIh6aN1XHWmvMWPlCqXsV8zQzk5SRbpRClRhlpq15spNbwM2IpOYt188//PYMD9MrAs++152pCAG2ra/YgNqQq1Ka07Sq2MA1Kmc5o3x+YpxcDlA7ErDAgHJRU67jPoGCB8TXy/k01I+0= 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=AX4pxzJL; arc=none smtp.client-ip=91.218.175.183 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="AX4pxzJL" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1766153918; 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=SSOy8Cv2+1AkhL8BhM42T0222pxUzx2sQzwDEXbtV+8=; b=AX4pxzJLOVFYlea43K/QolftJ3Keeh2NMfZvIZuh/6lZa9sB5nkLY2IzMxL28zVUX0a0I8 7x2TeyecP9tE59b/k60SXgr5F7MWKuGX0FITNO5/cmI6McrI5ixdZwQZWyCu8Usw1nwrSj oHoJTnNmurybiRtn3tyVz2/gzWye7p8= Date: Fri, 19 Dec 2025 22:18:30 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v3 2/2] hung_task: Enable runtime reset of hung_task_detect_count Content-Language: en-US To: Joel Granados Cc: Petr Mladek , akpm@linux-foundation.org, mhiramat@kernel.org, gregkh@linuxfoundation.org, sean@ashe.io, linux-kernel@vger.kernel.org, Aaron Tomlin References: <20251216030036.1822217-1-atomlin@atomlin.com> <20251216030036.1822217-3-atomlin@atomlin.com> <23d396d9-c055-4385-8a0f-c16fd24bedba@linux.dev> <4c2ewriu3tfrcz6ffxbmi2nozbhedwbffh4nizvoks6klfajzs@kshe6uxgzm6k> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <4c2ewriu3tfrcz6ffxbmi2nozbhedwbffh4nizvoks6klfajzs@kshe6uxgzm6k> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2025/12/18 17:08, Joel Granados wrote: > On Wed, Dec 17, 2025 at 09:21:01PM +0800, Lance Yang wrote: >> >> >> On 2025/12/17 20:48, Petr Mladek wrote: >>> Adding Joel into Cc. He is improving the sysctl API... >>> >>> On Mon 2025-12-15 22:00:36, Aaron Tomlin wrote: >>>> Introduce support for writing to /proc/sys/kernel/hung_task_detect_count. >>>> >>>> Writing any value to this file atomically resets the counter of detected >>>> hung tasks to zero. This grants system administrators the ability to clear >>>> the cumulative diagnostic history after resolving an incident, simplifying >>>> monitoring without requiring a system restart. > I see that this might be refactored due to dependency that was not > considered. I'll write my comments, but will also drop it from my radar > for now. > >>>> >>>> --- a/Documentation/admin-guide/sysctl/kernel.rst >>>> +++ b/Documentation/admin-guide/sysctl/kernel.rst >>>> @@ -418,7 +418,7 @@ hung_task_detect_count >>>> ====================== >>>> Indicates the total number of tasks that have been detected as hung since >>>> -the system boot. >>>> +the system boot. The counter can be reset to zero when written to. > Would it make more sense to write it like this: > > Indicates the total number of tasks that have been detected as hung > since the system boot or since the counter was reset. Counter is > zeroed when written to. > >>>> This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. >>>> diff --git a/kernel/hung_task.c b/kernel/hung_task.c >>>> index 5902573200c0..01ce46a107b0 100644 >>>> --- a/kernel/hung_task.c >>>> +++ b/kernel/hung_task.c >>>> @@ -375,6 +375,31 @@ static long hung_timeout_jiffies(unsigned long last_checked, >>>> } >>>> #ifdef CONFIG_SYSCTL >>>> + >>>> +/** >>>> + * proc_dohung_task_detect_count - proc handler for hung_task_detect_count >>>> + * @table: Pointer to the struct ctl_table definition for this proc entry >>>> + * @write: Flag indicating the operation >>>> + * @buffer: User space buffer for data transfer >>>> + * @lenp: Pointer to the length of the data being transferred >>>> + * @ppos: Pointer to the current file offset >>>> + * >>>> + * This handler is used for reading the current hung task detection count >>>> + * and for resetting it to zero when a write operation is performed. >>>> + * Returns 0 on success or a negative error code on failure. >>>> + */ >>>> +static int proc_dohung_task_detect_count(const struct ctl_table *table, int write, >>>> + void *buffer, size_t *lenp, loff_t *ppos) >>>> +{ >>>> + if (!write) >>>> + return proc_doulongvec_minmax(table, write, buffer, lenp, ppos); >>> >>> There have been some changes in the sysctl API recently, see >>> https://lore.kernel.org/lkml/20251016-jag-sysctl_conv-v2-0-a2f16529acc4@kernel.org/ >>> >>> They are backward compatible, so the above code works. But it would be >>> nice to make it up-to-date, namely: >>> >>> + Replace "write" with "dir" >>> + Use SYSCTL_USER_TO_KERN(dir) instead of (!write) >>> >>> >>>> + WRITE_ONCE(sysctl_hung_task_detect_count, 0); >>> >>> I might be too conservative. But it looks weird to allow clearing the >>> value by any write. It would be better to return -EINVAL for non-zero >>> values. This would require using a copy of struct ctl_table and read >>> the value into a temporary variable. >> >> That's okay, I think. See vmstat_refresh() for a similar pattern - it > You are correct but wouldn't it make more sense to zero it out only when > the write value passed by the user is zero. And return -EINVAL for any > other value? Fair point, let's return -EINVAL when user writes a non-zero value :)