[PATCH 0/3] Add and use abstraction for synchronize_rcu()

[PATCH 0/3] Add and use abstraction for synchronize_rcu()

[Philipp Stanner]

Just compile tested this series, but I did use commit 1 in my DmaFence
and it worked well.

Philipp Stanner (3):
  rust: sync: Add abstraction for synchronize_rcu()
  rust: revocable: Use safe synchronize_rcu() abstraction
  rust: sync: Use safe synchronize_rcu() abstraction in poll

 rust/kernel/revocable.rs | 5 ++---
 rust/kernel/sync/poll.rs | 6 ++----
 rust/kernel/sync/rcu.rs  | 8 ++++++++
 3 files changed, 12 insertions(+), 7 deletions(-)


base-commit: 43a393185e33e573a374c1d4f7ddf6481484ef8d
-- 
2.54.0

[PATCH 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Philipp Stanner]

synchronize_rcu() is a frequently used C function which is always safe
to be called.

Add a safe abstraction for synchronize_rcu().

Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
 rust/kernel/sync/rcu.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
index a32bef6e490b..9b9addf8fedf 100644
--- a/rust/kernel/sync/rcu.rs
+++ b/rust/kernel/sync/rcu.rs
@@ -50,3 +50,11 @@ fn drop(&mut self) {
 pub fn read_lock() -> Guard {
     Guard::new()
 }
+
+/// Wait for one RCU grace period.
+///
+/// You typically do this to wait for everyone holding a [`Guard`].
+pub fn synchronize_rcu() {
+    // SAFETY: `synchronize_rcu()` is always safe to be called. It just waits for a grace period.
+    unsafe { bindings::synchronize_rcu() };
+}
-- 
2.54.0

Re: [PATCH 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Philipp Stanner]

On Thu, 2026-06-18 at 11:59 +0200, Philipp Stanner wrote:
> synchronize_rcu() is a frequently used C function which is always safe
> to be called.
> 
> Add a safe abstraction for synchronize_rcu().
> 
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
>  rust/kernel/sync/rcu.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> index a32bef6e490b..9b9addf8fedf 100644
> --- a/rust/kernel/sync/rcu.rs
> +++ b/rust/kernel/sync/rcu.rs
> @@ -50,3 +50,11 @@ fn drop(&mut self) {
>  pub fn read_lock() -> Guard {
>      Guard::new()
>  }
> +
> +/// Wait for one RCU grace period.
> +///
> +/// You typically do this to wait for everyone holding a [`Guard`].
> +pub fn synchronize_rcu() {

Hm, should it actually be #[inline]?

In C nowadays usage of inline is discouraged ("compiler knows better").
Unsure how Rust handles it; is its compiler different?

Moreover, this would be an opportunity to change the naming convention
to rcu::synchronize()

But since Boqun & Alice are pushing for rcu::RcuKBox for the reason
that it seems desirable to explicitly highlight that that's a special
Box, I guess we should be consistent with that and also have "rcu" in
the name here.


P.

> +    // SAFETY: `synchronize_rcu()` is always safe to be called. It just waits for a grace period.
> +    unsafe { bindings::synchronize_rcu() };
> +}

Re: [PATCH 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Alice Ryhl]

On Thu, Jun 18, 2026 at 01:40:05PM +0200, Philipp Stanner wrote:
> On Thu, 2026-06-18 at 11:59 +0200, Philipp Stanner wrote:
> > synchronize_rcu() is a frequently used C function which is always safe
> > to be called.
> > 
> > Add a safe abstraction for synchronize_rcu().
> > 
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
> > ---
> >  rust/kernel/sync/rcu.rs | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> > index a32bef6e490b..9b9addf8fedf 100644
> > --- a/rust/kernel/sync/rcu.rs
> > +++ b/rust/kernel/sync/rcu.rs
> > @@ -50,3 +50,11 @@ fn drop(&mut self) {
> >  pub fn read_lock() -> Guard {
> >      Guard::new()
> >  }
> > +
> > +/// Wait for one RCU grace period.
> > +///
> > +/// You typically do this to wait for everyone holding a [`Guard`].
> > +pub fn synchronize_rcu() {
> 
> Hm, should it actually be #[inline]?
> 
> In C nowadays usage of inline is discouraged ("compiler knows better").
> Unsure how Rust handles it; is its compiler different?

If you don't mark it #[inline], then Rust is going to generate a
function for the Rust synchronize_rcu() wrapper just in case a module
wants to call it. The module might still decide to inline it, but
because there's the possibility that a module could choose not to inline
it, it will generate a wrapper in the core kernel.

For simple wrappers around C functions, we generally just want the
module to invoke the C function directly, so #[inline] is good here to
avoid the core kernel function.

> Moreover, this would be an opportunity to change the naming convention
> to rcu::synchronize()
> 
> But since Boqun & Alice are pushing for rcu::RcuKBox for the reason
> that it seems desirable to explicitly highlight that that's a special
> Box, I guess we should be consistent with that and also have "rcu" in
> the name here.

I prefer the naming of synchronize_rcu() here.

Alice

Re: [PATCH 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Philipp Stanner]

On Thu, 2026-06-18 at 11:47 +0000, Alice Ryhl wrote:
> On Thu, Jun 18, 2026 at 01:40:05PM +0200, Philipp Stanner wrote:
> > Moreover, this would be an opportunity to change the naming convention
> > to rcu::synchronize()
> > 
> > But since Boqun & Alice are pushing for rcu::RcuKBox for the reason
> > that it seems desirable to explicitly highlight that that's a special
> > Box, I guess we should be consistent with that and also have "rcu" in
> > the name here.
> 
> I prefer the naming of synchronize_rcu() here.

We might be tempted to at least call it rcu_synchronize(), though. It's
also RcuKBox, not KBoxRcu.

But I don't have hard emotions on that topic.


P.

> 
> Alice

Re: [PATCH 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Alice Ryhl]

On Thu, Jun 18, 2026 at 2:47 PM Philipp Stanner <phasta@mailbox.org> wrote:
>
> On Thu, 2026-06-18 at 11:47 +0000, Alice Ryhl wrote:
> > On Thu, Jun 18, 2026 at 01:40:05PM +0200, Philipp Stanner wrote:
> > > Moreover, this would be an opportunity to change the naming convention
> > > to rcu::synchronize()
> > >
> > > But since Boqun & Alice are pushing for rcu::RcuKBox for the reason
> > > that it seems desirable to explicitly highlight that that's a special
> > > Box, I guess we should be consistent with that and also have "rcu" in
> > > the name here.
> >
> > I prefer the naming of synchronize_rcu() here.
>
> We might be tempted to at least call it rcu_synchronize(), though. It's
> also RcuKBox, not KBoxRcu.
>
> But I don't have hard emotions on that topic.

I don't think we should change the C name without quite good reasons.

Alice

[PATCH 2/3] rust: revocable: Use safe synchronize_rcu() abstraction

[Philipp Stanner]

We now have a safe wrapper for the foreign function synchronize_rcu().

Use it in revocable.rs.

Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
 rust/kernel/revocable.rs | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/rust/kernel/revocable.rs b/rust/kernel/revocable.rs
index 0f4ae673256d..66d4ee38754c 100644
--- a/rust/kernel/revocable.rs
+++ b/rust/kernel/revocable.rs
@@ -7,7 +7,7 @@
 
 use pin_init::Wrapper;
 
-use crate::{bindings, prelude::*, sync::rcu, types::Opaque};
+use crate::{prelude::*, sync::rcu, types::Opaque};
 use core::{
     marker::PhantomData,
     ops::Deref,
@@ -161,8 +161,7 @@ unsafe fn revoke_internal<const SYNC: bool>(&self) -> bool {
 
         if revoke {
             if SYNC {
-                // SAFETY: Just an FFI call, there are no further requirements.
-                unsafe { bindings::synchronize_rcu() };
+                rcu::synchronize_rcu();
             }
 
             // SAFETY: We know `self.data` is valid because only one CPU can succeed the
-- 
2.54.0

[PATCH 3/3] rust: sync: Use safe synchronize_rcu() abstraction in poll

[Philipp Stanner]

We now have a safe wrapper for the foreign function synchronize_rcu().

Use it in poll.rs.

Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
 rust/kernel/sync/poll.rs | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/rust/kernel/sync/poll.rs b/rust/kernel/sync/poll.rs
index 0ec985d560c8..401cf4d3f35f 100644
--- a/rust/kernel/sync/poll.rs
+++ b/rust/kernel/sync/poll.rs
@@ -8,7 +8,7 @@
     bindings,
     fs::File,
     prelude::*,
-    sync::{CondVar, LockClassKey},
+    sync::{rcu::synchronize_rcu, CondVar, LockClassKey},
 };
 use core::{marker::PhantomData, ops::Deref};
 
@@ -99,8 +99,6 @@ fn drop(self: Pin<&mut Self>) {
         unsafe { bindings::__wake_up_pollfree(self.inner.wait_queue_head.get()) };
 
         // Wait for epoll items to be properly removed.
-        //
-        // SAFETY: Just an FFI call.
-        unsafe { bindings::synchronize_rcu() };
+        synchronize_rcu();
     }
 }
-- 
2.54.0

Re: [PATCH 3/3] rust: sync: Use safe synchronize_rcu() abstraction in poll

[Alice Ryhl]

On Thu, Jun 18, 2026 at 12:01 PM Philipp Stanner <phasta@kernel.org> wrote:
>
> We now have a safe wrapper for the foreign function synchronize_rcu().
>
> Use it in poll.rs.
>
> Signed-off-by: Philipp Stanner <phasta@kernel.org>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH 3/3] rust: sync: Use safe synchronize_rcu() abstraction in poll

[Onur Özkan]

On Thu, 18 Jun 2026 11:59:52 +0200
Philipp Stanner <phasta@kernel.org> wrote:

> We now have a safe wrapper for the foreign function synchronize_rcu().
> 
> Use it in poll.rs.
> 
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
>  rust/kernel/sync/poll.rs | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/rust/kernel/sync/poll.rs b/rust/kernel/sync/poll.rs
> index 0ec985d560c8..401cf4d3f35f 100644
> --- a/rust/kernel/sync/poll.rs
> +++ b/rust/kernel/sync/poll.rs
> @@ -8,7 +8,7 @@
>      bindings,
>      fs::File,
>      prelude::*,
> -    sync::{CondVar, LockClassKey},
> +    sync::{rcu::synchronize_rcu, CondVar, LockClassKey},

nit: Missing vertical import. Same in the other module as well.

Thanks,
Onur

>  };
>  use core::{marker::PhantomData, ops::Deref};
>  
> @@ -99,8 +99,6 @@ fn drop(self: Pin<&mut Self>) {
>          unsafe { bindings::__wake_up_pollfree(self.inner.wait_queue_head.get()) };
>  
>          // Wait for epoll items to be properly removed.
> -        //
> -        // SAFETY: Just an FFI call.
> -        unsafe { bindings::synchronize_rcu() };
> +        synchronize_rcu();
>      }
>  }
> -- 
> 2.54.0
>