rust: helpers: add SRCU helpers

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +112 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );
+        }

rust/kernel/sync/srcu.rs new file +44 -0

+
+        // Ensure all SRCU callbacks have been finished before freeing.
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::srcu_barrier(ptr) };
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::cleanup_srcu_struct(ptr) };
+    }
+}
+
+// SAFETY: `srcu_struct` may be shared and used across threads.
+unsafe impl Send for Srcu {}
+// SAFETY: `srcu_struct` may be shared and used concurrently.
+unsafe impl Sync for Srcu {}
+
+/// Guard for an active SRCU read-side critical section on a particular [`Srcu`].
+///
+/// Leaking this guard with [`core::mem::forget`] leaves the SRCU read-side
+/// critical section active and makes dropping the associated [`Srcu`] sleep forever.
+///
+/// # Invariants
+///
+/// `idx` is the index returned by `srcu_read_lock()` for `srcu`.
+#[must_use = "if unused, the lock will be immediately unlocked"]
+pub struct Guard<'a> {
+    srcu: &'a Srcu,
+    idx: i32,
+    _not_send: NotThreadSafe,
+}
+
+impl Guard<'_> {
+    /// Explicitly releases the SRCU read-side critical section.
+    #[inline]
+    pub fn unlock(self) {}
+}
+
+impl Drop for Guard<'_> {
+    #[inline]
+    fn drop(&mut self) {
+        // SAFETY: `Guard` is only constructible through `Srcu::read_lock()`,
+        // which returns a valid index for the SRCU instance.
+        unsafe { bindings::srcu_read_unlock(self.srcu.inner.get(), self.idx) };
+    }
+}

Signature · 1 line

2.51.2

Quoted 154 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +112 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );
+        }

rust/kernel/sync/srcu.rs line 122

Quoted 10 lines

rust/kernel/sync/srcu.rs new file +10 -0

+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Quoted 48 lines

rust/kernel/sync/srcu.rs new file +44 -0

+
+        // Ensure all SRCU callbacks have been finished before freeing.
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::srcu_barrier(ptr) };
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::cleanup_srcu_struct(ptr) };
+    }
+}
+
+// SAFETY: `srcu_struct` may be shared and used across threads.
+unsafe impl Send for Srcu {}
+// SAFETY: `srcu_struct` may be shared and used concurrently.
+unsafe impl Sync for Srcu {}
+
+/// Guard for an active SRCU read-side critical section on a particular [`Srcu`].
+///
+/// Leaking this guard with [`core::mem::forget`] leaves the SRCU read-side
+/// critical section active and makes dropping the associated [`Srcu`] sleep forever.
+///
+/// # Invariants
+///
+/// `idx` is the index returned by `srcu_read_lock()` for `srcu`.
+#[must_use = "if unused, the lock will be immediately unlocked"]
+pub struct Guard<'a> {
+    srcu: &'a Srcu,
+    idx: i32,
+    _not_send: NotThreadSafe,
+}
+
+impl Guard<'_> {
+    /// Explicitly releases the SRCU read-side critical section.
+    #[inline]
+    pub fn unlock(self) {}
+}
+
+impl Drop for Guard<'_> {
+    #[inline]
+    fn drop(&mut self) {
+        // SAFETY: `Guard` is only constructible through `Srcu::read_lock()`,
+        // which returns a valid index for the SRCU instance.
+        unsafe { bindings::srcu_read_unlock(self.srcu.inner.get(), self.idx) };
+    }
+}

Signature · 1 line

2.51.2

Quoted 148 lines · On Thu, 28 May 2026 11:20:10 +0300 Onur Özkan <[email protected]> wrote:

Quoted 145 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +103 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {

Quoted 8 lines

rust/kernel/sync/srcu.rs line 111

Quoted 8 lines

rust/kernel/sync/srcu.rs new file +8 -0

+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

Quoted 12 lines

rust/kernel/sync/srcu.rs line 122

Quoted 11 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

I have no plans for tomorrow other than finalizing this series including the question above.

Quoted 154 lines · Onur Özkan

Quoted 151 lines · On Thu, 28 May 2026 11:20:10 +0300 Onur Özkan <[email protected]> wrote:

Quoted 148 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +106 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`

Quoted 5 lines

Quoted 5 lines

rust/kernel/sync/srcu.rs line 111

Quoted 5 lines

rust/kernel/sync/srcu.rs new file +5 -0

+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

Quoted 28 lines

Quoted 13 lines

rust/kernel/sync/srcu.rs line 122

Quoted 12 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Best,
Gary

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

rust/kernel/sync/srcu.rs new file +6 -0

+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

rust/kernel/sync/srcu.rs line 111

Quoted 5 lines

rust/kernel/sync/srcu.rs new file +5 -0

+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

We also call cleanup_srcu_struct below. The idea was to provide additional information, we don't need to call warn_on twice.

Quoted 29 lines

Quoted 29 lines

Quoted 14 lines

rust/kernel/sync/srcu.rs line 122

Quoted 13 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 8 lines

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

The issue is difficult to fix purely from the C side. Once drop returns Rust is free to destroy srcu_struct. If srcu still has pending callback associated with that srcu_struct, for example from a future call_srcu() wrapper then returning from drop while readers are active can turn into a UAF. There is also no way to handle callbacks in a reasonable way in cleanup logic while there are active readers.

I mean in theory this could be fixed in the C code, but that would require to re-write srcu cores/semantics for this special case. The $clean_something helper would need know that the active readers are abandoned and will never unlock and it would also need to decide what to do with the pending callbacks, which is also a big problem (as gp will never complete, callbacks will never run).

It's also worth to note that calling mem::forget on the srcu guard is WRONG CODE and very easy to catch on review (by us and also Sashiko/any LLM). So finding a solution that doesn't add too much complexity should be a key consideration here. With that in mind, keeping the synchronize_srcu() not really a bad solution. Sleeping forever is a bad failure mode, but it is better than a potential UAF and either case requires sending a fix patch for the leaked guard anyway.

Quoted 15 lines · Onur Özkan

Quoted 14 lines

Quoted 11 lines

Quoted 11 lines

rust/kernel/sync/srcu.rs line 111

Quoted 11 lines

rust/kernel/sync/srcu.rs new file +11 -0

+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

Quoted 2 lines

We also call cleanup_srcu_struct below. The idea was to provide additional information, we don't need to call warn_on twice.

If the code blocks on synchronize_srcu then there's no call to cleanup_srcu_struct.

Quoted 40 lines

Quoted 30 lines

Quoted 30 lines

Quoted 15 lines

Quoted 4 lines

rust/kernel/sync/srcu.rs new file +1 -0

+        }

rust/kernel/sync/srcu.rs line 122

Quoted 10 lines

rust/kernel/sync/srcu.rs new file +10 -0

+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 8 lines

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Quoted 6 lines

The issue is difficult to fix purely from the C side. Once drop returns Rust is free to destroy srcu_struct. If srcu still has pending callback associated with that srcu_struct, for example from a future call_srcu() wrapper then returning from drop while readers are active can turn into a UAF. There is also no way to handle callbacks in a reasonable way in cleanup logic while there are active readers.

Callbacks should be flushed during the drop due to srcu_barrier. Am I missing something?

I'm pretty sure that, if we disregard potential misuses from C side, removing all "leak it" paths would be fine and won't leak to UAF if all users are from Rust side.

To be very clear, I am not advocating to actually implement this way. I agree with your conclusion below that this is broken code and a warning + blocking is good enough. This is really just my thoughts on your "is there a better option" question, and I think it's better in ideal world, but I think blocking is a good pragmatic choice.

Best,
Gary

Quoted 14 lines

I mean in theory this could be fixed in the C code, but that would require to re-write srcu cores/semantics for this special case. The $clean_something helper would need know that the active readers are abandoned and will never unlock and it would also need to decide what to do with the pending callbacks, which is also a big problem (as gp will never complete, callbacks will never run).

It's also worth to note that calling mem::forget on the srcu guard is WRONG CODE and very easy to catch on review (by us and also Sashiko/any LLM). So finding a solution that doesn't add too much complexity should be a key consideration here. With that in mind, keeping the synchronize_srcu() not really a bad solution. Sleeping forever is a bad failure mode, but it is better than a potential UAF and either case requires sending a fix patch for the leaked guard anyway.

Quoted 19 lines · On Fri, 29 May 2026 13:07:18 +0100 Gary Guo <[email protected]> wrote:

Quoted 17 lines · Onur Özkan

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

(quoted diff) +6 -0

+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

We also call cleanup_srcu_struct below. The idea was to provide additional information, we don't need to call warn_on twice.

Quoted 2 lines

If the code blocks on synchronize_srcu then there's no call to cleanup_srcu_struct.

Ah right. I can do that in this case but honestly it's still more informative with the current way. It explicitly tells you what the problem is.

Quoted 27 lines

Quoted 26 lines

Quoted 10 lines

Quoted 10 lines

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 8 lines

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

The issue is difficult to fix purely from the C side. Once drop returns Rust is free to destroy srcu_struct. If srcu still has pending callback associated with that srcu_struct, for example from a future call_srcu() wrapper then returning from drop while readers are active can turn into a UAF. There is also no way to handle callbacks in a reasonable way in cleanup logic while there are active readers.

Quoted 2 lines

Callbacks should be flushed during the drop due to srcu_barrier. Am I missing something?

No. Callbacks can only be invoked once the grace period has completed [1], which can never happen while there is an active reader.

[1]: https://elixir.bootlin.com/linux/v7.1-rc5/source/kernel/rcu/srcutree.c#L1452-L1454

Quoted 11 lines

I'm pretty sure that, if we disregard potential misuses from C side, removing all "leak it" paths would be fine and won't leak to UAF if all users are from Rust side.

To be very clear, I am not advocating to actually implement this way. I agree with your conclusion below that this is broken code and a warning + blocking is good enough. This is really just my thoughts on your "is there a better option" question, and I think it's better in ideal world, but I think blocking is a good pragmatic choice.

I see. Maybe I should have phrased the question like "Is there a better option with similar complexity" to be more clear.

Quoted 22 lines · Onur Özkan

Quoted 19 lines · On Fri, 29 May 2026 13:07:18 +0100 Gary Guo <[email protected]> wrote:

Quoted 17 lines · Onur Özkan

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

(quoted diff) +6 -0

+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {
+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

We also call cleanup_srcu_struct below. The idea was to provide additional information, we don't need to call warn_on twice.

Quoted 6 lines

Quoted 2 lines

If the code blocks on synchronize_srcu then there's no call to cleanup_srcu_struct.

Ah right. I can do that in this case but honestly it's still more informative with the current way. It explicitly tells you what the problem is.

While the error message itself is not that informative (there's some potential to improve this, see
https://lore.kernel.org/all/[email protected]/), the stack trace produced by a warn_on would have all the information and is more useful to troubleshoot than a pr_warn which doesn't tell you which Srcu being dropped is causing the issue.

Quoted 31 lines

Quoted 30 lines

Quoted 21 lines

Quoted 11 lines

Quoted 11 lines

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 8 lines

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Quoted 6 lines

The issue is difficult to fix purely from the C side. Once drop returns Rust is free to destroy srcu_struct. If srcu still has pending callback associated with that srcu_struct, for example from a future call_srcu() wrapper then returning from drop while readers are active can turn into a UAF. There is also no way to handle callbacks in a reasonable way in cleanup logic while there are active readers.

Callbacks should be flushed during the drop due to srcu_barrier. Am I missing something?

Quoted 4 lines

No. Callbacks can only be invoked once the grace period has completed [1], which can never happen while there is an active reader.

[1]: https://elixir.bootlin.com/linux/v7.1-rc5/source/kernel/rcu/srcutree.c#L1452-L1454

Well, then srcu_barrier will not return. When srcu_barrier returns all in-flight SRCU callbacks must have been executed.

Best,
Gary

Quoted 14 lines

Quoted 11 lines

I'm pretty sure that, if we disregard potential misuses from C side, removing all "leak it" paths would be fine and won't leak to UAF if all users are from Rust side.

To be very clear, I am not advocating to actually implement this way. I agree with your conclusion below that this is broken code and a warning + blocking is good enough. This is really just my thoughts on your "is there a better option" question, and I think it's better in ideal world, but I think blocking is a good pragmatic choice.

I see. Maybe I should have phrased the question like "Is there a better option with similar complexity" to be more clear.

Quoted 4 lines · On Fri, 29 May 2026 13:41:10 +0100 Gary Guo <[email protected]> wrote:

Quoted 3 lines · Onur Özkan

Quoted 1 line · On Fri, 29 May 2026 13:07:18 +0100 Gary Guo <[email protected]> wrote:

On Fri May 29, 2026 at 7:57 AM BST, Onur Özkan wrote:

Quoted 32 lines

Quoted 32 lines

Quoted 26 lines

Quoted 19 lines

Quoted 9 lines

Quoted 9 lines

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 8 lines

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Quoted 6 lines

The issue is difficult to fix purely from the C side. Once drop returns Rust is free to destroy srcu_struct. If srcu still has pending callback associated with that srcu_struct, for example from a future call_srcu() wrapper then returning from drop while readers are active can turn into a UAF. There is also no way to handle callbacks in a reasonable way in cleanup logic while there are active readers.

Quoted 2 lines

Callbacks should be flushed during the drop due to srcu_barrier. Am I missing something?

No. Callbacks can only be invoked once the grace period has completed [1], which can never happen while there is an active reader.

Quoted 4 lines

Quoted 1 line

[1]: https://elixir.bootlin.com/linux/v7.1-rc5/source/kernel/rcu/srcutree.c#L1452-L1454

Well, then srcu_barrier will not return. When srcu_barrier returns all in-flight SRCU callbacks must have been executed.

Yes, or there weren't any callbacks posted.

Quoted 17 lines

Best,
Gary

Quoted 14 lines

Quoted 11 lines

I'm pretty sure that, if we disregard potential misuses from C side, removing all "leak it" paths would be fine and won't leak to UAF if all users are from Rust side.

To be very clear, I am not advocating to actually implement this way. I agree with your conclusion below that this is broken code and a warning + blocking is good enough. This is really just my thoughts on your "is there a better option" question, and I think it's better in ideal world, but I think blocking is a good pragmatic choice.

I see. Maybe I should have phrased the question like "Is there a better option with similar complexity" to be more clear.

Quoted 151 lines · Onur Özkan

Quoted 148 lines · On Thu, 28 May 2026 11:20:10 +0300 Onur Özkan <[email protected]> wrote:

Quoted 145 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +103 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {

Quoted 8 lines

Quoted 8 lines

rust/kernel/sync/srcu.rs line 111

Quoted 8 lines

rust/kernel/sync/srcu.rs new file +8 -0

+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

Quoted 27 lines

Quoted 12 lines

rust/kernel/sync/srcu.rs line 122

Quoted 11 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

Quoted 2 lines

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Quoted 198 lines · Gary Guo

Quoted 151 lines · Onur Özkan

Quoted 148 lines · On Thu, 28 May 2026 11:20:10 +0300 Onur Özkan <[email protected]> wrote:

Quoted 145 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +103 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {

Quoted 8 lines

Quoted 8 lines

rust/kernel/sync/srcu.rs line 111

Quoted 8 lines

rust/kernel/sync/srcu.rs new file +8 -0

+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

Quoted 24 lines

Quoted 12 lines

rust/kernel/sync/srcu.rs line 122

Quoted 11 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

Quoted 5 lines

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

Quoted 1 line

This obviously require changes to the SRCU code though.

Right now, the C-language SRCU code would splat and leak the srcu_struct structure. Of course, we *could* provide something that zeroed the reader counts to avoid the splat and leak, but yikes! Or is there a way to make such a function available *only* to the Rust code associated with cleanup_srcu_struct(), and not to other C/Rust code?

Thanx, Paul

Quoted 201 lines · On Fri, 29 May 2026 08:36:16 -0700 "Paul E. McKenney" <[email protected]>…

Quoted 199 lines · Gary Guo

Quoted 151 lines · Onur Özkan

Quoted 148 lines · On Thu, 28 May 2026 11:20:10 +0300 Onur Özkan <[email protected]> wrote:

Quoted 145 lines · On Thu, 28 May 2026 09:27:35 +0300 Onur Özkan <[email protected]> wrote:

Add a Rust abstraction for sleepable RCU (SRCU), backed by C srcu_struct. Provide FFI helpers and a safe wrapper with a guard-based API for read-side critical sections.

Cleanup is handled via PinnedDrop, which explicitly drains pending grace periods and callbacks via synchronize_srcu and srcu_barrier before executing cleanup_srcu_struct to guarantee memory safety e.g. when there are leaked guards (via mem::forget($guard)).

Signed-off-by Onur Özkan <[email protected]>

---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 168 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

rust/kernel/sync.rs +2 -0

index 993dbf2caa0e..0d6a5f1300c3 100644
@@ -21,6 +21,7 @@
 pub mod rcu;
 mod refcount;
 mod set_once;
+pub mod srcu;
 
 pub use arc::{Arc, ArcBorrow, UniqueArc};
 pub use completion::Completion;

@@ -31,6 +32,7 @@
 pub use locked_by::LockedBy;
 pub use refcount::Refcount;
 pub use set_once::SetOnce;
+pub use srcu::Srcu;
 
 /// Represents a lockdep class.
 ///

rust/kernel/sync/srcu.rs new file +103 -0

new file mode 100644
index 000000000000..343f00d070c7
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Sleepable read-copy update (SRCU) support.
+//!
+//! C header: [`include/linux/srcu.h`](srctree/include/linux/srcu.h)
+
+use crate::{
+    bindings,
+    error::to_result,
+    prelude::*,
+    sync::LockClassKey,
+    types::{
+        NotThreadSafe,
+        Opaque, //
+    },
+};
+
+use pin_init::pin_data;
+
+/// Creates an [`Srcu`] initialiser with the given name and a newly-created lock class.
+#[doc(hidden)]
+#[macro_export]
+macro_rules! new_srcu {
+    ($($name:literal)?) => {
+        $crate::sync::Srcu::new($crate::optional_name!($($name)?), $crate::static_lock_class!())
+    };
+}
+pub use new_srcu;
+
+/// Sleepable read-copy update primitive.
+///
+/// SRCU readers may sleep while holding the read-side guard.
+///
+/// The destructor waits for active readers and callbacks, so it may sleep.
+/// If a read-side guard has been leaked, dropping an [`Srcu`] may never return.
+///
+/// # Invariants
+///
+/// This represents a valid `struct srcu_struct` initialized by the C SRCU API
+/// and it remains pinned and valid until the pinned destructor runs.
+#[repr(transparent)]
+#[pin_data(PinnedDrop)]
+pub struct Srcu {
+    #[pin]
+    inner: Opaque<bindings::srcu_struct>,
+}
+
+impl Srcu {
+    /// Creates a new SRCU instance.
+    #[inline]
+    pub fn new(name: &'static CStr, key: Pin<&'static LockClassKey>) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            // INVARIANT: On success, the C initializer creates a valid `srcu_struct` and
+            // it remains pinned until `PinnedDrop` runs.
+            inner <- Opaque::try_ffi_init(|ptr: *mut bindings::srcu_struct| {
+                // SAFETY: `ptr` points to valid uninitialised memory for a `srcu_struct`.
+                to_result(unsafe {
+                    bindings::init_srcu_struct_with_key(ptr, name.as_char_ptr(), key.as_ptr())
+                })
+            }),
+        })
+    }
+
+    /// Enters an SRCU read-side critical section.
+    ///
+    /// Leaking the returned [`Guard`] leaves the SRCU read-side critical
+    /// section active and makes `drop` sleep forever.
+    #[inline]
+    pub fn read_lock(&self) -> Guard<'_> {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        let idx = unsafe { bindings::srcu_read_lock(self.inner.get()) };
+
+        // INVARIANT: `idx` was returned by `srcu_read_lock()` for this `Srcu`.
+        Guard {
+            srcu: self,
+            idx,
+            _not_send: NotThreadSafe,
+        }
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed.
+    #[inline]
+    pub fn synchronize(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(self.inner.get()) };
+    }
+
+    /// Waits until all pre-existing SRCU readers have completed, expedited.
+    ///
+    /// This requests a lower-latency grace period than [`Srcu::synchronize`] typically
+    /// at the cost of higher system-wide overhead. Prefer [`Srcu::synchronize`] by default
+    /// and use this variant only when reducing reset or teardown latency is more important
+    /// than the extra cost.
+    #[inline]
+    pub fn synchronize_expedited(&self) {
+        // SAFETY: By the type invariants, `self` contains a valid `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu_expedited(self.inner.get()) };
+    }
+}
+
+#[pinned_drop]
+impl PinnedDrop for Srcu {
+    fn drop(self: Pin<&mut Self>) {

Quoted 8 lines

Quoted 8 lines

rust/kernel/sync/srcu.rs line 111

Quoted 8 lines

rust/kernel/sync/srcu.rs new file +8 -0

+        let ptr = self.inner.get();
+
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
+        // and `srcu_readers_active()` only checks the active reader count.
+        if unsafe { bindings::srcu_readers_active(ptr) } {
+            crate::pr_warn!(
+                "Leaked `Guard` detected while dropping SRCU; drop will block forever.\n"
+            );

I think this could be a warn_on similar to how cleanup_srcu_struct handle the condition.

Quoted 24 lines

Quoted 12 lines

rust/kernel/sync/srcu.rs line 122

Quoted 11 lines

rust/kernel/sync/srcu.rs new file +11 -0

+        }
+
+        // `cleanup_srcu_struct()` may return early if readers are still active. Because `Srcu`
+        // owns the embedded `srcu_struct`, returning from `drop` in that state could free memory
+        // that is still referenced by the C side.
+        //
+        // Wait for all readers to complete first. If any `Guard` was leaked, `synchronize_srcu()`
+        // will sleep forever.
+        //
+        // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`.
+        unsafe { bindings::synchronize_srcu(ptr) };

Quoted 5 lines

Sashiko got a good point here which is calling synchronize_srcu() only if there are active readers. That's a nice low-effort improvement we can have in the next version.

Onur

Actually, now I am now thinking about whether we can come up with a better approach when we detect leaked guards. Initially I came up with the synchronize_srcu() solution because it would handle leaked guards automatically without requiring any additional checks. But now that we can actually detect whether guards are leaked the question becomes:

Quoted 5 lines

"Is there a better option than effectively sleeping forever when leaked
guards are detected?"

I have no plans for tomorrow other than finalizing this series including the question above.

The best solution is to proceed cleanups anyway, given Rust rules ensure that these are actual leaks and not just srcu read-side critical section that failed to synchronize with the destruction of SRCU.

This obviously require changes to the SRCU code though.

Quoted 5 lines

Right now, the C-language SRCU code would splat and leak the srcu_struct structure. Of course, we *could* provide something that zeroed the reader counts to avoid the splat and leak, but yikes! Or is there a way to make such a function available *only* to the Rust code associated with cleanup_srcu_struct(), and not to other C/Rust code?

Anyone can use them if they want from bindings:: once it's exposed to Rust.

Regards,
Onur

Quoted 1 line

Thanx, Paul

Is there a Rust-language counterpart to checkpatch.pl that could warn when it sees patches adding calls to this function?

Quoted 3 lines · Paul E. McKenney

Is there a Rust-language counterpart to checkpatch.pl that could warn when it sees patches adding calls to this function?

We had some patches for proposed Rust checks for checkpatch.pl, so it could be there (there was also a proposed rust_checkpatch.pl).

Having said that, Clippy's disallowed_methods is likely better (modulo bugs), and we already have a couple entries on it (please see .clippy.toml in the root). So I would suggest that first.

There is also Klint if something more custom/complex is needed.

Cheers,
Miguel

I am waiting for the v9 [1] reviews. If we get a complain on the current approach we can consider the Rust-specific clean-up C function + disallowed_methods from Clippy.

Quoted 4 lines · Onur Özkan

I am waiting for the v9 [1] reviews. If we get a complain on the current approach we can consider the Rust-specific clean-up C function + disallowed_methods from Clippy.

Just to clarify, I only meant to reply to Paul about linting in Rust in general, i.e. I didn't mean to ask for a particular approach here.

The immediate motivation is the Tyr reset infrastructure [1] which needs to serialize reset sensitive hardware access against reset and teardown paths. That reset series started to require many independent dependencies so this SRCU support is split out as a standalone Rust API to keep the reset series focused on the reset logic and easier to review, rebase and land.

Changes since v6:

- Removed "CONFIG_DEBUG_LOCK_ALLOC" condition from "rust/helpers/srcu.c" and created a simple wrapper inside "include/linux/srcu.h" for it.

v6: https://lore.kernel.org/all/[email protected]

Changes since v5:

- Created separate srcu_readers_active() variants for "srcutiny.h" and "srcutree.h".

v5: https://lore.kernel.org/all/[email protected]

Changes since v4:

- Exposed srcu_readers_active from C side and wired it to the Rust helpers.
- Used srcu_readers_active() in SRCU drop and logged with pr_warn if there are leaked guards during the drop.

v4: https://lore.kernel.org/all/[email protected]

Changes since v3 (which are for Sashiko notes [2]):

- Added rust helpers for srcu_barrier() and synchronize_srcu_expedited() so the abstraction builds with CONFIG_TINY_SRCU, where these are static inline functions.
- Added missing INVARIANT comment in Srcu::new() about why the type invariants hold after successful initialization.

v3: https://lore.kernel.org/all/[email protected]

Changes since v2:

- Removed closure-based API.
- Added #[doc(hidden)] on new_srcu macro.
- Added #[must_use..] on srcu::Guard.
- Improved the clean-up path (PinnedDrop implementation) which eventually made read_lock safe with leaked guards.

v2: https://lore.kernel.org/all/[email protected]

Changes since v1:

- Made the owned SRCU read-side guard API unsafe and added a safe closure based helper for callers that do not need to keep the guard. This is to avoid UB on the C side cleanup_srcu_struct where the SRCU struct is freed while there are still active guards, which can happen if the caller leaks the guard e.g., with mem::forget().
- Improved doc comments.

v1: https://lore.kernel.org/all/[email protected]

[1]: https://lore.kernel.org/all/[email protected]
[2]: https://sashiko.dev/#/patchset/[email protected]?part=2

Onur Özkan (4):
rust: helpers: add SRCU helpers
srcu: expose srcu_readers_active()
rust: sync: add SRCU abstraction
MAINTAINERS: add Rust SRCU files to SRCU entry

 MAINTAINERS              |   3 +
 include/linux/srcu.h     |   5 ++
 include/linux/srcutiny.h |  13 +++
 include/linux/srcutree.h |  24 ++++++
 kernel/rcu/srcutiny.c    |   2 +-
 kernel/rcu/srcutree.c    |  25 ------
 rust/helpers/helpers.c   |   1 +
 rust/helpers/srcu.c      |  35 +++++++++
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 166 +++++++++++++++++++++++++++++++++++++++
 10 files changed, 250 insertions(+), 26 deletions(-)
 create mode 100644 rust/helpers/srcu.c
 create mode 100644 rust/kernel/sync/srcu.rs

Signature · 1 line

2.51.2