From: Mitchell Levy <levymitchell0@gmail.com>
To: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Dennis Zhou" <dennis@kernel.org>, "Tejun Heo" <tj@kernel.org>,
"Christoph Lameter" <cl@linux.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-mm@kvack.org, Mitchell Levy <levymitchell0@gmail.com>
Subject: [PATCH RFC 0/3] rust: Add Per-CPU Variable API
Date: Thu, 19 Dec 2024 13:08:25 -0800 [thread overview]
Message-ID: <20241219-rust-percpu-v1-0-209117e822b1@gmail.com> (raw)
This series adds an API for declaring an using per-CPU variables from
Rust, and it also adds support for Rust access to C per-CPU variables
(subject to some soundness requirements). It also adds a small test
module, lib/percpu_test_rust.rs, in the vein of lib/percpu_test.c.
---
I am sending this patch as an RFC to gather feedback on the API as well
as get some input on correctness. In particular, the unsafe getter macro
is somewhat cumbersome, though its safety requirements for pure-Rust
code aren't too difficult to verify (interoperation with C code is
certainly much more tricky).
It was suggested that I base my implementation on Rust's thread-local
storage API. However, this API requires that for a thread-local T, any
particular usage must be via a &T. Thus, many times it is required that
thread-local variables be in the form RefCell<T> or Cell<T>. This has
some pretty severe disadvantages in the context of per-CPU variables.
Namely, RefCell<T> may panic if .borrow_mut is called multiple times at
different points in the call stack. This is similar to the problem
inherent in my current implementation (that is, unsafe_get_per_cpu_ref
must be used carefully so as to not create aliasing mut references), but
this implementation flags this potential problem via an unsafe block and
the resulting PerCpuRef can be easily passed along and used fairly
easily. Cell<T> on the other hand requires a copy any time the
underlying value is used, which is entirely avoided here.
Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
---
Mitchell Levy (3):
rust: percpu: introduce a rust API for per-CPU variables
rust: rust-analyzer: add lib to dirs searched for crates
rust: percpu: add a rust per-CPU variable test
lib/Kconfig.debug | 9 +++
lib/Makefile | 1 +
lib/percpu_test_rust.rs | 65 +++++++++++++++
rust/helpers/helpers.c | 1 +
rust/helpers/preempt.c | 14 ++++
rust/kernel/lib.rs | 3 +
rust/kernel/percpu.rs | 161 ++++++++++++++++++++++++++++++++++++++
rust/kernel/percpu/cpu_guard.rs | 29 +++++++
scripts/generate_rust_analyzer.py | 2 +-
9 files changed, 284 insertions(+), 1 deletion(-)
---
base-commit: 0c5928deada15a8d075516e6e0d9ee19011bb000
change-id: 20240813-rust-percpu-ea2f54b5da33
Best regards,
--
Mitchell Levy <levymitchell0@gmail.com>
next reply other threads:[~2024-12-19 21:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 21:08 Mitchell Levy [this message]
2024-12-19 21:08 ` [PATCH RFC 1/3] rust: percpu: introduce a rust API for per-CPU variables Mitchell Levy
2024-12-19 21:08 ` [PATCH RFC 2/3] rust: rust-analyzer: add lib to dirs searched for crates Mitchell Levy
2024-12-19 21:08 ` [PATCH RFC 3/3] rust: percpu: add a rust per-CPU variable test Mitchell Levy
2024-12-20 17:56 ` Christoph Lameter (Ampere)
2024-12-30 18:37 ` Boqun Feng
2025-01-05 13:01 ` Charalampos Mitrodimas
2025-01-07 23:41 ` Mitchell Levy
2025-01-08 16:18 ` Charalampos Mitrodimas
2025-01-04 22:45 ` [PATCH RFC 0/3] rust: Add Per-CPU Variable API Dennis Zhou
2025-01-07 23:39 ` Mitchell Levy
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=20241219-rust-percpu-v1-0-209117e822b1@gmail.com \
--to=levymitchell0@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=cl@linux.com \
--cc=dennis@kernel.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tj@kernel.org \
--cc=tmgross@umich.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