On Sat, May 30, 2026 at 04:35:10PM +0200, Philipp Stanner wrote:
> From: Alice Ryhl <[email protected]>
> 

A few minor things below:

[...]
> diff --git a/rust/kernel/sync/rcu/rcu_box.rs b/rust/kernel/sync/rcu/rcu_box.rs
> new file mode 100644
> index 000000000000..2508fdb609ec
> --- /dev/null
> +++ b/rust/kernel/sync/rcu/rcu_box.rs
> @@ -0,0 +1,145 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// Copyright (C) 2026 Google LLC.
> +
> +//! Provides the `RcuBox` type for Rust allocations that live for a grace 
> period.
> +
> +use core::{ops::Deref, ptr::NonNull};
> +
> +use kernel::{

Let's use `crate::` here since RcuBox is part of the kernel crate.

> +    alloc::{self, AllocError},
> +    bindings,
> +    ffi::c_void,
> +    prelude::*,
> +    sync::rcu::{ForeignOwnableRcu, Guard},
> +    types::ForeignOwnable,
> +};
> +
> +/// A box that is freed with rcu.
> +///
> +/// The value must be `Send`, as rcu may drop it on another thread.
> +///
> +/// # Invariants
> +///
> +/// * The pointer is valid and references a pinned `RcuBoxInner<T>` 
> allocated with `kmalloc`.
> +/// * This `RcuBox` holds exclusive permissions to rcu free the allocation.
> +pub struct RcuBox<T: Send>(NonNull<RcuBoxInner<T>>);
> +
> +struct RcuBoxInner<T> {
> +    value: T,
> +    rcu_head: bindings::callback_head,

Probably should reorder these fields.

> +}
> +
> +// Note that `T: Sync` is required since when moving an `RcuBox<T>`, the 
> previous owner may still
> +// access `&T` for one grace period.
> +//
> +// SAFETY: Ownership of the `RcuBox<T>` allows for `&T` and dropping the 
> `T`, so `T: Send + Sync`
> +// implies `RcuBox<T>: Send`.
> +unsafe impl<T: Send + Sync> Send for RcuBox<T> {}
> +
> +// SAFETY: `&RcuBox<T>` allows for no operations other than those permitted 
> by `&T`, so `T: Sync`
> +// implies `RcuBox<T>: Sync`.
> +unsafe impl<T: Send + Sync> Sync for RcuBox<T> {}

@Alice, we have `T: Send` mostly because `RcuBox` itself has the `T:
Send` bound? I.e. the to be `Sync` we actually don't need `T` being
`Send`, right?

Regards,
Boqun

[...]

Reply via email to