Rust for Linux List
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Priya Bala Govindasamy" <pgovind2@uci.edu>, <rafael@kernel.org>,
	<viresh.kumar@linaro.org>, <ojeda@kernel.org>,
	<aliceryhl@google.com>, <boqun@kernel.org>,
	<rust-for-linux@vger.kernel.org>, <linux-pm@vger.kernel.org>
Cc: <ardalan@uci.edu>, <zhiyunq@cs.ucr.edu>, <dzueck@uci.edu>,
	<ytan089@ucr.edu>
Subject: Re: [PATCH v2] rust: cpufreq: Fix temporary write in Registration::bios_limit_callback
Date: Sat, 18 Jul 2026 16:35:28 +0100	[thread overview]
Message-ID: <DK1T30ZOCE1U.Z8SR05WTWLL0@garyguo.net> (raw)
In-Reply-To: <2fd4425697efb6d52459cd886115edd281bd5f44.1784155370.git.pgovind2@uci.edu>

On Sat Jul 18, 2026 at 12:35 AM BST, Priya Bala Govindasamy wrote:
> In `Registration::bios_limit_callback`, the expression
> `&mut (unsafe { *limit })` creates a reference to a temporary copy
> of the value pointed to by `limit` on the stack.
> Therefore, writes made by `T::bios_limit` go to this temporary
> instead of the memory location pointed to by `limit`.
>
> Additionally, `limit` may be uninitialized, such as when
> `Registration::bios_limit_callback` is invoked by `show_bios_limit`
> in drivers/cpufreq/cpufreq.c. Therefore dereferencing `limit` is
> unsound.
>
> Fix this by changing the signature of `T::bios_limit` to return the limit
> value.
> `Registration::bios_limit_callback` can then update `limit` directly.
>
> Fixes: c6af9a1191d042839e56abff69e8b0302d117988 ("rust: cpufreq: Extend abstractions for driver registration")
> Reported-by: Dylan Zueck<dzueck@uci.edu>
> Reported-by: Yuan Tan<ytan089@ucr.edu>
> Signed-off-by: Priya Bala Govindasamy<pgovind2@uci.edu>
> Assisted-by: ChatGPT:gpt-5.4

You should move this line above your S-o-b. This tag should be covered by your
S-o-b, not by whoever applies this patch.

>
> changes in v2:
>  - Change the signature of `T::bios_limit` and have
>    `Registration::bios_limit_callback` write to `limit` directly instead of initializing `limit` to zero first and passing a mutable reference of `limit` to `T::bios_limit`
>  - v1 Link: https://lore.kernel.org/rust-for-linux/cover.1783456063.git.pgovind2@uci.edu/T/#t
> ---
>  rust/kernel/cpufreq.rs | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index 58ac04c650a1..5dc09063f4e9 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -817,7 +817,9 @@ fn update_limits(_policy: &mut Policy) {
>      }
>  
>      /// Driver's `bios_limit` callback.
> -    fn bios_limit(_policy: &mut Policy, _limit: &mut u32) -> Result {
> +    ///
> +    /// Returns the limit

The exisitng documentation is pointless. This really should just get proper
documentation, e.g.

    /// Returns HW/BIOS max frequency limitations for the CPU.

> +    fn bios_limit(_policy: &mut Policy) -> Result<u32> {
>          build_error!(VTABLE_DEFAULT_ERROR)
>      }
>  
> @@ -1352,9 +1354,10 @@ impl<T: Driver> Registration<T> {
>  
>          from_result(|| {
>              let mut policy = PolicyCpu::from_cpu(cpu_id)?;
> -
> +            let val = T::bios_limit(&mut policy)?;
>              // SAFETY: `limit` is guaranteed by the C code to be valid.
> -            T::bios_limit(&mut policy, &mut (unsafe { *limit })).map(|()| 0)
> +            unsafe { core::ptr::write(limit, val); }

This is primitive so there's no dropping of old value, so this can just be

    unsafe { *limit = val; }

Best,
Gary

> +            Ok(0)
>          })
>      }
>  



      reply	other threads:[~2026-07-18 15:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 23:35 [PATCH v2] rust: cpufreq: Fix temporary write in Registration::bios_limit_callback Priya Bala Govindasamy
2026-07-18 15:35 ` Gary Guo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DK1T30ZOCE1U.Z8SR05WTWLL0@garyguo.net \
    --to=gary@garyguo.net \
    --cc=aliceryhl@google.com \
    --cc=ardalan@uci.edu \
    --cc=boqun@kernel.org \
    --cc=dzueck@uci.edu \
    --cc=linux-pm@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pgovind2@uci.edu \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=viresh.kumar@linaro.org \
    --cc=ytan089@ucr.edu \
    --cc=zhiyunq@cs.ucr.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox