On Tue, 2026-06-23 at 09:56 +0100, Pedro Falcato wrote: > On Mon, Jun 22, 2026 at 07:32:49PM +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 | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs > > index a32bef6e490b..0d438ef31766 100644 > > --- a/rust/kernel/sync/rcu.rs > > +++ b/rust/kernel/sync/rcu.rs > > @@ -50,3 +50,12 @@ 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`]. > > +#[inline] > > +pub fn synchronize_rcu() { > > + // SAFETY: `synchronize_rcu()` is always safe to be called. It just > > waits for a grace period. > > Commething randomly here (I know as much rust as the next > not-knowing-rust-guy, sadly), > but synchronize_rcu() is not always safe to be called. You cannot call it if > you have the rcu read lock, or cannot sleep for any reason. I don't know if > you can encode these in the rust type system though.
Preventing illegal actions in atomic context seems very difficult to achieve in Rust and AFAIK the only viable path forward currently is to have klint check for rule violations. Gary is working on that. But it would be interesting to know more about how in general Rust's unsafe comments are related to problems beyond UAF issues, and to what degree we want to document context requirements. C documents functions like synchronize_rcu() in much detail, but its documentation trusts on the readers general familiarity with RCU, assuming no one would come up with the idea of calling synchronize_rcu() in an atomic context. P.
