Re: [PATCH v9 3/5] rust: sync: Add abstraction for rcu_barrier()

"Gary Guo" <[email protected]>
Newsgroups org.kernel.vger.rcu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Wed Aug 5, 2026 at 3:59 PM BST, Philipp Stanner wrote:
> rcu_barrier() is a frequently used C function which is always safe to be
> called.
>
> Add a safe abstraction for rcu_barrier().
>
> Signed-off-by: Philipp Stanner <[email protected]>
> Tested-by: Daniel Almeida <[email protected]>

Acked-by: Gary Guo <[email protected]>

> ---
>  rust/kernel/sync/rcu.rs | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> index a32bef6e490b..7031ca5d2473 100644
> --- a/rust/kernel/sync/rcu.rs
> +++ b/rust/kernel/sync/rcu.rs
> @@ -50,3 +50,23 @@ fn drop(&mut self) {
>  pub fn read_lock() -> Guard {
>      Guard::new()
>  }
> +
> +/// Wait until all in-flight call_rcu() callbacks complete.

This misses some `` quoting but these can be applied on fixup.

Best,
Gary

> +///
> +/// Note that this primitive does not necessarily wait for an RCU grace period
> +/// to complete.  For example, if there are no RCU callbacks queued anywhere
> +/// in the system, then rcu_barrier() is within its rights to return
> +/// immediately, without waiting for anything, much less an RCU grace period.
> +/// In fact, rcu_barrier() will normally not result in any RCU grace periods
> +/// beyond those that were already destined to be executed.
> +///
> +/// In kernels built with CONFIG_RCU_LAZY=y, this function also hurries all
> +/// pending lazy RCU callbacks.
> +///
> +/// Note that this is one of the RCU primitives which must not be called in
> +/// atomic context.
> +#[inline]
> +pub fn rcu_barrier() {
> +    // SAFETY: `rcu_barrier()` is always safe to be called. It just might wait for a grace period.
> +    unsafe { bindings::rcu_barrier() };
> +}
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.