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: <ll74yi3miktap7ljxx2fenzhqanqikk5pibvcpfhqed6k3eugj@yga4f4yjzndo>
Date: Sun, 30 Nov 2025 12:11:55 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Lance Yang <lance.yang@...ux.dev>
Cc: linux-kernel@...r.kernel.org, mhiramat@...nel.org, 
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org, Petr Mladek <pmladek@...e.com>
Subject: Re: [PATCH] hung_task: Migrate hung_task_detect_count to sysfs

On Sun, Nov 30, 2025 at 01:43:51PM +0800, Lance Yang wrote:
> Hi Aaron,

Hi Lance,


> Thanks for the patch.

No problem.

> Emm, I don't think we should do this :)
> 
> Removing the sysctl file is going to break userspace tools that
> currently read it ...

Thank you for your feedback. I appreciate the concern regarding user-space
compatibility and the potential maintenance overhead of dual interfaces.

I agree that removing the sysctl entry entirely right now is too
disruptive, as it would immediately break existing user-space tools relying
on /proc/sys/kernel/hung_task_detect_count. Your point about avoiding
unnecessary churn and maintaining two interfaces is well-taken.

However, I believe that moving the counter to sysfs is still a worthwhile
long-term goal for the following reasons:

    1. Consistency and standardisation: Moving read-only counters to
       /sys/kernel/ aligns with current kernel conventions and provides a
       more consistent location for performance and diagnostic metrics.
       This follows the pattern of existing counters like
       /sys/kernel/softlockup_count.

    2. Graceful Migration Path: By adding the 
       /sys/kernel/hung_task_detect_count entry first (as a read-only
       counter) and keeping the legacy
       /proc/sys/kernel/hung_task_detect_count file in place, we provide
       the necessary backwards compatibility and offer a grace period for
       user-space tools to migrate. The old sysctl file can then be flagged
       for deprecation in a future release.

I am currently working on some additional updates for kernel/hung_task.c.
I believe integrating the sysfs entry now, while I am already touching this
file, would be an efficient and worthwhile start.

My proposal is to modify the patch to add the sysfs entry while preserving
the existing sysctl entry for the immediate future. If you agree that this
phased migration is a worthwhile endeavor, I will prepare and submit a v2
patch that implements this dual-interface approach.

Please let me know your thoughts on this approach for phased migration.


Thanks,
-- 
Aaron Tomlin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ