linux-kernel - Re: [PATCH V6 02/15] cpufreq: Add cpufreq_table

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] [day] [month] [year] [list]

Message-ID: <2025011327-cubbyhole-idealness-d4cc@gregkh>
Date: Mon, 13 Jan 2025 08:53:28 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Danilo Krummrich <dakr@...hat.com>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	linux-pm@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>,
	rust-for-linux@...r.kernel.org,
	Manos Pitsidianakis <manos.pitsidianakis@...aro.org>,
	Erik Schilling <erik.schilling@...aro.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Joakim Bech <joakim.bech@...aro.org>, Rob Herring <robh@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V6 02/15] cpufreq: Add cpufreq_table_len()

On Mon, Jan 13, 2025 at 01:00:40PM +0530, Viresh Kumar wrote:
> On 09-01-25, 08:35, Greg KH wrote:
> > Then why not make the C code use this function as well, to keep all
> > cpufreq drivers from having to manually walk the list and that way both
> > C and Rust drivers all do the same thing?  That makes more sense to me,
> > there's no reason you can't change C code today first to make things
> > more unified, in fact, that's usually a better idea overall anyway.
> 
> I investigated a bit on this..
> 
> - The cpufreq core normally gets (from cpufreq governor's for example)
>   a frequency value to be matched against in the freq-table, and the
>   loop which run over the freq-table is already optimized enough (it
>   checks for CPUFREQ_TABLE_END) for this. Using length in this loop
>   won't improve it anymore.
> 
> - The cpufreq core then calls cpufreq driver's callbacks and passes an
>   index to the freq-table, which the drivers don't need to verify
>   against table length, since the index came from the core itself.
> 
> - The same happens on the Rust side, where the cpufreq core calls the
>   target_index() callback of the driver. While writing the Rust code,
>   I thought maybe I should validate that the index is within limits
>   (before I do pointer manipulation in Rust code). And so required
>   this extra function (which C code never uses).
> 
> - Now I can either keep doing this verification in the Rust code (and
>   so keep the new API, only used by Rust code). Or I can just remove
>   the verification and trust that the index passed by the
>   cpufreq-drivers is correct (since they have received them from the
>   cpufreq C code).
> 
> What should I do ?

I would trust the C code, keeping the apis the same between the two
types of drivers.  If in the future you want to fix up the api, then fix
both drivers.  Don't try to have unique apis for only Rust drivers if
you can help it at all, that is just going to drive us all crazy over
time.

And really, you might want to fix up the api, that too sounds crazy :)

thanks,

greg k-h