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 <[email protected]> > > --- > > 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
