From: Boqun Feng <boqun.feng@gmail.com>
To: rust-for-linux@vger.kernel.org, rcu@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
llvm@lists.linux.dev, lkmm@lists.linux.dev
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@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@samsung.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Andrea Parri" <parri.andrea@gmail.com>,
"Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Nicholas Piggin" <npiggin@gmail.com>,
"David Howells" <dhowells@redhat.com>,
"Jade Alglave" <j.alglave@ucl.ac.uk>,
"Luc Maranget" <luc.maranget@inria.fr>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Akira Yokosawa" <akiyks@gmail.com>,
"Daniel Lustig" <dlustig@nvidia.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
kent.overstreet@gmail.com,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
elver@google.com, "Mark Rutland" <mark.rutland@arm.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
torvalds@linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, "Trevor Gross" <tmgross@umich.edu>,
dakr@redhat.com, "Frederic Weisbecker" <frederic@kernel.org>,
"Neeraj Upadhyay" <neeraj.upadhyay@kernel.org>,
"Josh Triplett" <josh@joshtriplett.org>,
"Uladzislau Rezki" <urezki@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org
Subject: [RFC v2 02/13] rust: sync: Add basic atomic operation mapping framework
Date: Thu, 31 Oct 2024 23:02:25 -0700 [thread overview]
Message-ID: <20241101060237.1185533-3-boqun.feng@gmail.com> (raw)
In-Reply-To: <20241101060237.1185533-1-boqun.feng@gmail.com>
Preparation for generic atomic implementation. To unify the
ipmlementation of a generic method over `i32` and `i64`, the C side
atomic methods need to be grouped so that in a generic method, they can
be referred as <type>::<method>, otherwise their parameters and return
value are different between `i32` and `i64`, which would require using
`transmute()` to unify the type into a `T`.
Introduce `AtomicIpml` to represent a basic type in Rust that has the
direct mapping to an atomic implementation from C. This trait is sealed,
and currently only `i32` and `i64` ipml this.
Further, different methods are put into different `*Ops` trait groups,
and this is for the future when smaller types like `i8`/`i16` are
supported but only with a limited set of API (e.g. only set(), load(),
xchg() and cmpxchg(), no add() or sub() etc).
While the atomic mod is introduced, documentation is also added for
memory models and data races.
Also bump my role to the maintainer of ATOMIC INFRASTRUCTURE to reflect
my responsiblity on the Rust atomic mod.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
MAINTAINERS | 4 +-
rust/kernel/sync.rs | 1 +
rust/kernel/sync/atomic.rs | 19 ++++
rust/kernel/sync/atomic/ops.rs | 199 +++++++++++++++++++++++++++++++++
4 files changed, 222 insertions(+), 1 deletion(-)
create mode 100644 rust/kernel/sync/atomic.rs
create mode 100644 rust/kernel/sync/atomic/ops.rs
diff --git a/MAINTAINERS b/MAINTAINERS
index b77f4495dcf4..e09471027a63 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3635,7 +3635,7 @@ F: drivers/input/touchscreen/atmel_mxt_ts.c
ATOMIC INFRASTRUCTURE
M: Will Deacon <will@kernel.org>
M: Peter Zijlstra <peterz@infradead.org>
-R: Boqun Feng <boqun.feng@gmail.com>
+M: Boqun Feng <boqun.feng@gmail.com>
R: Mark Rutland <mark.rutland@arm.com>
L: linux-kernel@vger.kernel.org
S: Maintained
@@ -3644,6 +3644,8 @@ F: arch/*/include/asm/atomic*.h
F: include/*/atomic*.h
F: include/linux/refcount.h
F: scripts/atomic/
+F: rust/kernel/sync/atomic.rs
+F: rust/kernel/sync/atomic/
ATTO EXPRESSSAS SAS/SATA RAID SCSI DRIVER
M: Bradley Grove <linuxdrivers@attotech.com>
diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 0ab20975a3b5..66ac3752ca71 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -8,6 +8,7 @@
use crate::types::Opaque;
mod arc;
+pub mod atomic;
mod condvar;
pub mod lock;
mod locked_by;
diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs
new file mode 100644
index 000000000000..21b87563667e
--- /dev/null
+++ b/rust/kernel/sync/atomic.rs
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Atomic primitives.
+//!
+//! These primitives have the same semantics as their C counterparts: and the precise definitions of
+//! semantics can be found at [`LKMM`]. Note that Linux Kernel Memory (Consistency) Model is the
+//! only model for Rust code in kernel, and Rust's own atomics should be avoided.
+//!
+//! # Data races
+//!
+//! [`LKMM`] atomics have different rules regarding data races:
+//!
+//! - A normal read doesn't data-race with an atomic read.
+//! - A normal write from C side is treated as an atomic write if
+//! CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y.
+//!
+//! [`LKMM`]: srctree/tools/memory-mode/
+
+pub mod ops;
diff --git a/rust/kernel/sync/atomic/ops.rs b/rust/kernel/sync/atomic/ops.rs
new file mode 100644
index 000000000000..59101a0d0273
--- /dev/null
+++ b/rust/kernel/sync/atomic/ops.rs
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Atomic implementations.
+//!
+//! Provides 1:1 mapping of atomic implementations.
+
+use crate::bindings::*;
+use crate::macros::paste;
+
+mod private {
+ /// Sealed trait marker to disable customized impls on atomic implementation traits.
+ pub trait Sealed {}
+}
+
+// `i32` and `i64` are only supported atomic implementations.
+impl private::Sealed for i32 {}
+impl private::Sealed for i64 {}
+
+/// A marker trait for types that ipmlement atomic operations with C side primitives.
+///
+/// This trait is sealed, and only types that have directly mapping to the C side atomics should
+/// impl this:
+///
+/// - `i32` maps to `atomic_t`.
+/// - `i64` maps to `atomic64_t`.
+pub trait AtomicImpl: Sized + Send + Copy + private::Sealed {}
+
+// `atomic_t` impl atomic operations on `i32`.
+impl AtomicImpl for i32 {}
+
+// `atomic64_t` impl atomic operations on `i64`.
+impl AtomicImpl for i64 {}
+
+// This macro generates the function signature with given argument list and return type.
+macro_rules! declare_atomic_method {
+ (
+ $func:ident($($arg:ident : $arg_type:ty),*) $(-> $ret:ty)?
+ ) => {
+ paste!(
+ #[doc = concat!("Atomic ", stringify!($func))]
+ #[doc = "# Safety"]
+ #[doc = "- any pointer passed to the function has to be a valid pointer"]
+ #[doc = "- Accesses must not cause data races per LKMM:"]
+ #[doc = " - atomic read racing with normal read, normal write or atomic write is not data race."]
+ #[doc = " - atomic write racing with normal read or normal write is data-race, unless the"]
+ #[doc = " normal accesses are done at C side and considered as immune to data"]
+ #[doc = " races, e.g. CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC."]
+ unsafe fn [< atomic_ $func >]($($arg: $arg_type,)*) $(-> $ret)?;
+ );
+ };
+ (
+ $func:ident [$variant:ident $($rest:ident)*]($($arg_sig:tt)*) $(-> $ret:ty)?
+ ) => {
+ paste!(
+ declare_atomic_method!(
+ [< $func _ $variant >]($($arg_sig)*) $(-> $ret)?
+ );
+ );
+
+ declare_atomic_method!(
+ $func [$($rest)*]($($arg_sig)*) $(-> $ret)?
+ );
+ };
+ (
+ $func:ident []($($arg_sig:tt)*) $(-> $ret:ty)?
+ ) => {
+ declare_atomic_method!(
+ $func($($arg_sig)*) $(-> $ret)?
+ );
+ }
+}
+
+// This macro generates the function implementation with given argument list and return type, and it
+// will replace "call(...)" expression with "$ctype _ $func" to call the real C function.
+macro_rules! impl_atomic_method {
+ (
+ ($ctype:ident) $func:ident($($arg:ident: $arg_type:ty),*) $(-> $ret:ty)? {
+ call($($c_arg:expr),*)
+ }
+ ) => {
+ paste!(
+ #[inline(always)]
+ unsafe fn [< atomic_ $func >]($($arg: $arg_type,)*) $(-> $ret)? {
+ // SAFETY: Per function safety requirement, all pointers are valid, and accesses
+ // won't cause data race per LKMM.
+ unsafe { [< $ctype _ $func >]($($c_arg,)*) }
+ }
+ );
+ };
+ (
+ ($ctype:ident) $func:ident[$variant:ident $($rest:ident)*]($($arg_sig:tt)*) $(-> $ret:ty)? {
+ call($($arg:tt)*)
+ }
+ ) => {
+ paste!(
+ impl_atomic_method!(
+ ($ctype) [< $func _ $variant >]($($arg_sig)*) $( -> $ret)? {
+ call($($arg)*)
+ }
+ );
+ );
+ impl_atomic_method!(
+ ($ctype) $func [$($rest)*]($($arg_sig)*) $( -> $ret)? {
+ call($($arg)*)
+ }
+ );
+ };
+ (
+ ($ctype:ident) $func:ident[]($($arg_sig:tt)*) $( -> $ret:ty)? {
+ call($($arg:tt)*)
+ }
+ ) => {
+ impl_atomic_method!(
+ ($ctype) $func($($arg_sig)*) $(-> $ret)? {
+ call($($arg)*)
+ }
+ );
+ }
+}
+
+// Delcares $ops trait with methods and implements the trait for `i32` and `i64`.
+macro_rules! declare_and_impl_atomic_methods {
+ ($ops:ident ($doc:literal) {
+ $(
+ $func:ident [$($variant:ident),*]($($arg_sig:tt)*) $( -> $ret:ty)? {
+ call($($arg:tt)*)
+ }
+ )*
+ }) => {
+ #[doc = $doc]
+ pub trait $ops: AtomicImpl {
+ $(
+ declare_atomic_method!(
+ $func[$($variant)*]($($arg_sig)*) $(-> $ret)?
+ );
+ )*
+ }
+
+ impl $ops for i32 {
+ $(
+ impl_atomic_method!(
+ (atomic) $func[$($variant)*]($($arg_sig)*) $(-> $ret)? {
+ call($($arg)*)
+ }
+ );
+ )*
+ }
+
+ impl $ops for i64 {
+ $(
+ impl_atomic_method!(
+ (atomic64) $func[$($variant)*]($($arg_sig)*) $(-> $ret)? {
+ call($($arg)*)
+ }
+ );
+ )*
+ }
+ }
+}
+
+declare_and_impl_atomic_methods!(
+ AtomicHasBasicOps ("Basic atomic operations") {
+ read[acquire](ptr: *mut Self) -> Self {
+ call(ptr as *mut _)
+ }
+
+ set[release](ptr: *mut Self, v: Self) {
+ call(ptr as *mut _, v)
+ }
+ }
+);
+
+declare_and_impl_atomic_methods!(
+ AtomicHasXchgOps ("Exchange and compare-and-exchange atomic operations") {
+ xchg[acquire, release, relaxed](ptr: *mut Self, v: Self) -> Self {
+ call(ptr as *mut _, v)
+ }
+
+ cmpxchg[acquire, release, relaxed](ptr: *mut Self, old: Self, new: Self) -> Self {
+ call(ptr as *mut _, old, new)
+ }
+
+ try_cmpxchg[acquire, release, relaxed](ptr: *mut Self, old: *mut Self, new: Self) -> bool {
+ call(ptr as *mut _, old, new)
+ }
+ }
+);
+
+declare_and_impl_atomic_methods!(
+ AtomicHasArithmeticOps ("Atomic arithmetic operations") {
+ add[](ptr: *mut Self, v: Self) {
+ call(v, ptr as *mut _)
+ }
+
+ fetch_add[acquire, release, relaxed](ptr: *mut Self, v: Self) -> Self {
+ call(v, ptr as *mut _)
+ }
+ }
+);
--
2.45.2
next prev parent reply other threads:[~2024-11-01 6:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 6:02 [RFC v2 00/13] LKMM *generic* atomics in Rust Boqun Feng
2024-11-01 6:02 ` [RFC v2 01/13] rust: Introduce atomic API helpers Boqun Feng
2024-11-01 6:02 ` Boqun Feng [this message]
2024-12-12 10:51 ` [RFC v2 02/13] rust: sync: Add basic atomic operation mapping framework Alice Ryhl
2024-12-12 17:07 ` Boqun Feng
2024-12-13 14:37 ` Alice Ryhl
2024-12-13 20:28 ` Boqun Feng
2024-11-01 6:02 ` [RFC v2 03/13] rust: sync: atomic: Add ordering annotation types Boqun Feng
2024-11-01 6:02 ` [RFC v2 04/13] rust: sync: atomic: Add generic atomics Boqun Feng
2024-12-12 10:57 ` Alice Ryhl
2024-12-12 17:34 ` Boqun Feng
2024-12-13 14:32 ` Alice Ryhl
2024-12-13 20:13 ` Boqun Feng
2024-11-01 6:02 ` [RFC v2 05/13] rust: sync: atomic: Add atomic {cmp,}xchg operations Boqun Feng
2024-11-01 6:02 ` [RFC v2 06/13] rust: sync: atomic: Add the framework of arithmetic operations Boqun Feng
2024-11-01 6:02 ` [RFC v2 07/13] rust: sync: atomic: Add Atomic<u{32,64}> Boqun Feng
2024-11-01 6:02 ` [RFC v2 08/13] rust: sync: atomic: Add Atomic<{usize,isize}> Boqun Feng
2024-11-01 6:02 ` [RFC v2 09/13] rust: sync: atomic: Add Atomic<*mut T> Boqun Feng
2024-11-01 6:02 ` [RFC v2 10/13] rust: sync: atomic: Add arithmetic ops for " Boqun Feng
2024-11-01 6:02 ` [RFC v2 11/13] rust: sync: Add memory barriers Boqun Feng
2024-11-01 6:55 ` David Gow
2024-11-01 7:04 ` Boqun Feng
2024-11-01 7:01 ` [RFC v2.1 " Boqun Feng
2024-11-01 6:02 ` [RFC v2 12/13] rust: add rcu abstraction Boqun Feng
2024-11-01 6:02 ` [RFC v2 13/13] rust: sync: rcu: Add RCU protected pointer Boqun Feng
2024-11-01 14:30 ` [RFC v2 00/13] LKMM *generic* atomics in Rust Miguel Ojeda
2024-11-02 7:35 ` David Gow
2025-04-21 16:27 ` Boqun Feng
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=20241101060237.1185533-3-boqun.feng@gmail.com \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=akiyks@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dakr@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=elver@google.com \
--cc=frederic@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=j.alglave@ucl.ac.uk \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kent.overstreet@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lkmm@lists.linux.dev \
--cc=llvm@lists.linux.dev \
--cc=luc.maranget@inria.fr \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=npiggin@gmail.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=parri.andrea@gmail.com \
--cc=paul.walmsley@sifive.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=tmgross@umich.edu \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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