linux-kernel - Re: [v5 PATCH 2/2] hung_task: Enable runtime reset of hung_task_detect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lspa5nhgj6iyx74tyattuxenyglfvis2dk5khkdrtro45yfcv4@4br4cjt3imvu>
Date: Mon, 5 Jan 2026 11:53:08 +0100
From: Joel Granados <joel.granados@...nel.org>
To: Aaron Tomlin <atomlin@...mlin.com>
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 Thu, Jan 01, 2026 at 08:24:42PM -0500, Aaron Tomlin wrote:
> 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
It is clear to me that you need a custom handler after changing the type
to an atomic_long_t.

It is not clear to my why you changed it to atomic_long_t. It was
already being modified,read,written when it was a raw unsigned long.
What has changed that requires atomic_long_t?

Best


-- 

Joel Granados

Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)