[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <px6ujeiuw3uqehrswtro2miv74ouzelgnnrx7o6nrqhejm7s3f@rsjhd4uo7w3v>
Date: Thu, 1 Jan 2026 20:24:42 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Joel Granados <joel.granados@...nel.org>
Cc: akpm@...ux-foundation.org, lance.yang@...ux.dev, mhiramat@...nel.org,
gregkh@...uxfoundation.org, pmladek@...e.com, sean@...e.io, linux-kernel@...r.kernel.org
Subject: Re: [v5 PATCH 2/2] hung_task: Enable runtime reset of
hung_task_detect_count
On Fri, Jan 02, 2026 at 12:14:39AM +0100, Joel Granados wrote:
> I don't understand why do you need a custom proc_handler here.
> Couldn't you just do this:
> {
> .procname = "hung_task_detect_count",
> .data = &sysctl_hung_task_detect_count,
> .maxlen = sizeof(unsigned long),
> .mode = 0644,
> .proc_handler = proc_doulongvec_minmax,
> .extra1 = 0,
> .extra2 = 0,
> },
>
> ???
>
> What a I missing?
Hi Joel,
The reason for the custom handler is that sysctl_hung_task_detect_count is
now an atomic_long_t.
The generic proc_doulongvec_minmax() handler expects a pointer to a raw
unsigned long and performs standard assignments. If we pointed it directly
at an atomic type, we would lose the atomicity and memory barriers required
for the reset logic to work correctly alongside check_hung_task().
The custom handler acts as a wrapper to ensure we use atomic_long_read()
and atomic_long_set(), while also enforcing the policy that only a value of
'0' is valid for writing
Kind regards,
--
Aaron Tomlin
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists