linux-kernel - Re: [PATCH V2 1/2] rust: cpu: Introduce CpuId abstraction

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: <20250610083933.2xwl5wz4drs4mgk4@vireshk-i7>
Date: Tue, 10 Jun 2025 14:09:33 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Yury Norov <yury.norov@...il.com>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/2] rust: cpu: Introduce CpuId abstraction

On 09-06-25, 07:04, Boqun Feng wrote:
> I think you can keep this as a separate patch for the ease of review.
> And I just realize that we should use raw_smp_processor_id() because
> the current API only support an unstable cpuid read. For a stable cpuid
> read, we need some lifetime description of the return value to make sure
> it doesn't outlive the scope that guarantees the cpuid is stable. Well,
> the user can still use the unstable CpuId and ensure the scope provides
> the cpuid stability (see comments of smp_processor_id()), it's just
> CpuId::current() doesn't need to guarantee that.
 
> We need mention that the result is an unstable one, and refer to the
> raw_smp_processor_id() in include/linux/smp.h (we probably also want to
> fix the typo there, i.e. s/raw_processor_id/raw_smp_processor_id, while
> we are at it). Also it's worth mentioning that if the context between
> CpuId::current() and use of the return value indeed guarantee cpuid
> stability, the users can treat it as a stable one.

Thanks. How about this:

Subject: [PATCH] rust: cpu: Add CpuId::current() to retrieve current CPU ID

Introduce `CpuId::current()`, a constructor that wraps the C function
`raw_smp_processor_id()` to retrieve the current CPU identifier without
guaranteeing stability.

This function should be used only when the caller can ensure that
the CPU ID won't change unexpectedly due to preemption or migration.

Suggested-by: Boqun Feng <boqun.feng@...il.com>
Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 rust/helpers/cpu.c     |  8 ++++++++
 rust/helpers/helpers.c |  1 +
 rust/kernel/cpu.rs     | 10 ++++++++++
 3 files changed, 19 insertions(+)
 create mode 100644 rust/helpers/cpu.c

diff --git a/rust/helpers/cpu.c b/rust/helpers/cpu.c
new file mode 100644
index 000000000000..824e0adb19d4
--- /dev/null
+++ b/rust/helpers/cpu.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/smp.h>
+
+unsigned int rust_helper_raw_smp_processor_id(void)
+{
+	return raw_smp_processor_id();
+}
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 0f1b5d115985..16fa9bca5949 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -13,6 +13,7 @@
 #include "build_assert.c"
 #include "build_bug.c"
 #include "clk.c"
+#include "cpu.c"
 #include "cpufreq.c"
 #include "cpumask.c"
 #include "cred.c"
diff --git a/rust/kernel/cpu.rs b/rust/kernel/cpu.rs
index fbc47d2814df..fd2240fe6e2d 100644
--- a/rust/kernel/cpu.rs
+++ b/rust/kernel/cpu.rs
@@ -99,6 +99,16 @@ pub fn from_u32(id: u32) -> Option<Self> {
     pub fn as_u32(&self) -> u32 {
         self.0
     }
+
+    /// Returns the ID of the CPU the code is currently running on.
+    ///
+    /// The returned value is considered unstable because it may change
+    /// unexpectedly due to preemption or CPU migration. It should only be
+    /// used when the context ensures that the task remains on the same CPU.
+    pub fn current() -> Self {
+        // SAFETY: raw_smp_processor_id() always returns a valid CPU ID.
+        unsafe { Self::from_u32_unchecked(bindings::raw_smp_processor_id()) }
+    }
 }
 
 impl From<CpuId> for u32 {

-- 
viresh