linux-kernel - Re: [v6 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 for Android: free password hash cracker in your pocket

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

Message-ID: <9e8c49cb-cbf9-4cdf-8dea-9abbb03e05a4@linux.dev>
Date: Fri, 16 Jan 2026 10:10:57 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: sean@...e.io, linux-kernel@...r.kernel.org, pmladek@...e.com,
 gregkh@...uxfoundation.org, mhiramat@...nel.org, akpm@...ux-foundation.org,
 joel.granados@...nel.org
Subject: Re: [v6 PATCH 2/2] hung_task: Enable runtime reset of
 hung_task_detect_count



On 2026/1/16 02:24, Aaron Tomlin wrote:
> On Thu, Jan 15, 2026 at 11:06:16AM +0800, Lance Yang wrote:
>> I see hung_task_diagnostics() is still in this patch. I thought
>> we'd concluded that[1] the refactoring wasn't really necessary for a
>> single-use block?
>>
>> [1] https://lore.kernel.org/all/noze3vhqjbsuulvvoaw4h5yeinggpwfslrit5vsd2dllfo4ath@qgmp22hoibgn/
> 
> Hi Lance,
> 
> Please accept my apologies for the oversight; I certainly did not intend to
> disregard our previous conclusion regarding the refactoring.
> 
> However, in light of the additional modifications suggested by Petr, it
> appeared to me that re-introducing hung_task_diagnostics() resulted in a
> significantly cleaner implementation. By encapsulating the diagnostic
> output logic, we separate the formatting concerns from the control flow,
> which seemed to improve the overall readability of the function.
> 
> That being said, if you still consider this abstraction to be redundant, I
> am entirely amenable to dropping it and reverting to the inline approach.
> 
> Please let me know your preference.

Thanks for explaining!

Personally, I still do not think the helper is necessary here.

Especially for a single-use block, the abstraction doesn't add much
value.

The inline version is actually more straightforward - you can see
the diagnostic output right where it's used without jumping to another
function.

Please drop the helper and keep that code inline :)