lkml.org 
[lkml]   [2023]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[RFC] rust: types: Add read_once and write_once
    Date
    In theory, `read_volatile` and `write_volatile` in Rust can have UB in
    case of the data races [1]. However, kernel uses volatiles to implement
    READ_ONCE() and WRITE_ONCE(), and expects races on these marked accesses
    don't cause UB. And they are proven to have a lot of usages in kernel.

    To close this gap, `read_once` and `write_once` are introduced, they
    have the same semantics as `READ_ONCE` and `WRITE_ONCE` especially
    regarding data races under the assumption that `read_volatile` and
    `write_volatile` have the same behavior as a volatile pointer in C from
    a compiler point of view.

    Longer term solution is to work with Rust language side for a better way
    to implement `read_once` and `write_once`. But so far, it should be good
    enough.

    Suggested-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://doc.rust-lang.org/std/ptr/fn.read_volatile.html#safety [1]
    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    ---

    Notice I also make the primitives only work on T: Copy, since I don't
    think Rust side and C side will use a !Copy type to communicate, but we
    can always remove that constrait later.


    rust/kernel/prelude.rs | 2 ++
    rust/kernel/types.rs | 43 ++++++++++++++++++++++++++++++++++++++++++
    2 files changed, 45 insertions(+)

    diff --git a/rust/kernel/prelude.rs b/rust/kernel/prelude.rs
    index ae21600970b3..351ad182bc63 100644
    --- a/rust/kernel/prelude.rs
    +++ b/rust/kernel/prelude.rs
    @@ -38,3 +38,5 @@
    pub use super::init::{InPlaceInit, Init, PinInit};

    pub use super::current;
    +
    +pub use super::types::{read_once, write_once};
    diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
    index d849e1979ac7..b0872f751f97 100644
    --- a/rust/kernel/types.rs
    +++ b/rust/kernel/types.rs
    @@ -432,3 +432,46 @@ pub enum Either<L, R> {
    /// Constructs an instance of [`Either`] containing a value of type `R`.
    Right(R),
    }
    +
    +/// (Concurrent) Primitives to interact with C side, which are considered as marked access:
    +///
    +/// tools/memory-memory/Documentation/access-marking.txt
    +
    +/// The counter part of C `READ_ONCE()`.
    +///
    +/// The semantics is exactly the same as `READ_ONCE()`, especially when used for intentional data
    +/// races.
    +///
    +/// # Safety
    +///
    +/// * `src` must be valid for reads.
    +/// * `src` must be properly aligned.
    +/// * `src` must point to a properly initialized value of value `T`.
    +#[inline(always)]
    +pub unsafe fn read_once<T: Copy>(src: *const T) -> T {
    + // SAFETY: the read is valid because of the function's safety requirement, plus the assumption
    + // here is that 1) a volatile pointer dereference in C and 2) a `read_volatile` in Rust have the
    + // same semantics, so this function should have the same behavior as `READ_ONCE()` regarding
    + // data races.
    + unsafe { src.read_volatile() }
    +}
    +
    +/// The counter part of C `WRITE_ONCE()`.
    +///
    +/// The semantics is exactly the same as `WRITE_ONCE()`, especially when used for intentional data
    +/// races.
    +///
    +/// # Safety
    +///
    +/// * `dst` must be valid for writes.
    +/// * `dst` must be properly aligned.
    +#[inline(always)]
    +pub unsafe fn write_once<T: Copy>(dst: *mut T, value: T) {
    + // SAFETY: the write is valid because of the function's safety requirement, plus the assumption
    + // here is that 1) a write to a volatile pointer dereference in C and 2) a `write_volatile` in
    + // Rust have the same semantics, so this function should have the same behavior as
    + // `WRITE_ONCE()` regarding data races.
    + unsafe {
    + core::ptr::write_volatile(dst, value);
    + }
    +}
    --
    2.41.0
    \
     
     \ /
      Last update: 2023-10-25 21:55    [W:3.744 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site