All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Joel Granados <joel.granados@kernel.org>
Cc: Petr Mladek <pmladek@suse.com>,
	akpm@linux-foundation.org, mhiramat@kernel.org,
	gregkh@linuxfoundation.org, sean@ashe.io,
	linux-kernel@vger.kernel.org, Aaron Tomlin <atomlin@atomlin.com>
Subject: Re: [PATCH v3 2/2] hung_task: Enable runtime reset of hung_task_detect_count
Date: Fri, 19 Dec 2025 22:18:30 +0800	[thread overview]
Message-ID: <fc76c670-128c-49f3-a3f4-814625609817@linux.dev> (raw)
In-Reply-To: <4c2ewriu3tfrcz6ffxbmi2nozbhedwbffh4nizvoks6klfajzs@kshe6uxgzm6k>



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 :)


  reply	other threads:[~2025-12-19 14:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16  3:00 [PATCH v3 0/2] hung_task: Provide runtime reset interface for hung task detector Aaron Tomlin
2025-12-16  3:00 ` [PATCH v3 1/2] hung_task: Introduce helper for hung task warning Aaron Tomlin
2025-12-17  9:39   ` Petr Mladek
2025-12-21 21:52     ` Aaron Tomlin
2025-12-16  3:00 ` [PATCH v3 2/2] hung_task: Enable runtime reset of hung_task_detect_count Aaron Tomlin
2025-12-17  7:31   ` Lance Yang
2025-12-17 13:09     ` Petr Mladek
2025-12-17 13:36       ` Lance Yang
2025-12-19  3:09       ` Aaron Tomlin
2025-12-19 12:03         ` Petr Mladek
2025-12-19 14:15           ` Lance Yang
2025-12-21 21:00             ` Aaron Tomlin
2025-12-17 12:48   ` Petr Mladek
2025-12-17 13:21     ` Lance Yang
2025-12-18  9:08       ` Joel Granados
2025-12-19 14:18         ` Lance Yang [this message]
2025-12-21 21:26         ` 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=fc76c670-128c-49f3-a3f4-814625609817@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.