linux-kernel - Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

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: <CAJZ5v0j3Mpo2LLGN+jWbNi4vT+u+Wckm5NK+ehA=GhigThpcnA@mail.gmail.com>
Date: Fri, 21 Nov 2025 14:31:44 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, daniel.lezcano@...aro.org, 
	gregkh@...uxfoundation.org, nathan@...nel.org, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] cpuidle: sysfs: Display idle state enter function name

On Fri, Nov 21, 2025 at 4:16 AM Aaron Tomlin <atomlin@...mlin.com> wrote:
>
> On Thu, Nov 20, 2025 at 04:36:21PM +0100, Rafael J. Wysocki wrote:
> > I'm not really sure how this helps.
> >
> > For example, the intel_idle driver uses the same function for all idle
> > states except for the polling one, which is already advertised as
> > polling.
> >
> > Besides, why do you want users to look into the kernel source code to
> > figure things out?
>
> Hi Rafael,
>
> While intel_idle uses a single function for most states today, other
> cpuidle drivers, different architectures, or future changes might implement
> per-state variations.
>
> The mapping from abstract C-state names and descriptions (e.g., "C1", "C3")
> to the actual kernel implementation might not always be clear. Exposing the
> enter function offers a direct, cheap and reliable way to easily identify
> what is being executed for each state without using a kernel debugger
> (e.g., crash(8). Finally user-space tools might benefit from introspecting
> implementation details at runtime to validate configuration. This is
> primarily for the advanced user.
>
> Please let me know if this clarifies the motivation.

No, it doesn't.  You'd need to tell me specifically what use case is
going to be addressed by this change.

Though this is not going to fly regardless because exposing kernel
internals via sysfs turns them into ABI which may hinder future
improvements.

So let's first talk about what problem there is that needs addressing.