[PATCH v8 0/4] rust: helpers: add SRCU helpers

[PATCH v8 0/4] rust: helpers: add SRCU helpers

[Onur Özkan]

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 v7:

- Moved synchronize_srcu() call inside "if srcu_readers_active()"
  condition in "impl PinnedDrop for Srcu".
- Improved comments on the synchronize_srcu() call in
  "impl PinnedDrop for Srcu".

v7: https://lore.kernel.org/all/20260528062810.256212-1-work@onurozkan.dev

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/20260527203615.163688-1-work@onurozkan.dev

Changes since v5:

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

v5: https://lore.kernel.org/all/20260527174120.510447-1-work@onurozkan.dev

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/20260525175706.124910-1-work@onurozkan.dev

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/20260522054228.114814-1-work@onurozkan.dev

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/20260502162833.34334-1-work@onurozkan.dev

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/20260428103437.156236-1-work@onurozkan.dev


[1]: https://lore.kernel.org/all/20260416171728.205141-1-work@onurozkan.dev
[2]: https://sashiko.dev/#/patchset/20260522054228.114814-1-work@onurozkan.dev?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 | 173 +++++++++++++++++++++++++++++++++++++++
 10 files changed, 257 insertions(+), 26 deletions(-)
 create mode 100644 rust/helpers/srcu.c
 create mode 100644 rust/kernel/sync/srcu.rs

-- 
2.51.2

[PATCH v8 1/4] rust: helpers: add SRCU helpers

[Onur Özkan]

Add helper wrappers for SRCU functions that are exposed to Rust
through generated bindings.

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 include/linux/srcu.h   |  5 +++++
 rust/helpers/helpers.c |  1 +
 rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 rust/helpers/srcu.c

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 81b1938512d5..790a4ef713c0 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
 #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
 
 int init_srcu_struct(struct srcu_struct *ssp);
+static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
+				     struct lock_class_key *key)
+{
+	return init_srcu_struct(ssp);
+}
 #ifndef CONFIG_TINY_SRCU
 int init_srcu_struct_fast(struct srcu_struct *ssp);
 int init_srcu_struct_fast_updown(struct srcu_struct *ssp);
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index 625921e27dfb..f3562d3b3888 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -88,6 +88,7 @@
 #include "signal.c"
 #include "slab.c"
 #include "spinlock.c"
+#include "srcu.c"
 #include "sync.c"
 #include "task.c"
 #include "time.c"
diff --git a/rust/helpers/srcu.c b/rust/helpers/srcu.c
new file mode 100644
index 000000000000..225b3bf9334a
--- /dev/null
+++ b/rust/helpers/srcu.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/srcu.h>
+
+__rust_helper int rust_helper_init_srcu_struct_with_key(struct srcu_struct *ssp,
+							const char *name,
+							struct lock_class_key *key)
+{
+	return __init_srcu_struct(ssp, name, key);
+}
+
+__rust_helper int rust_helper_srcu_read_lock(struct srcu_struct *ssp)
+{
+	return srcu_read_lock(ssp);
+}
+
+__rust_helper void rust_helper_srcu_read_unlock(struct srcu_struct *ssp, int idx)
+{
+	srcu_read_unlock(ssp, idx);
+}
+
+__rust_helper void rust_helper_srcu_barrier(struct srcu_struct *ssp)
+{
+	srcu_barrier(ssp);
+}
+
+__rust_helper void rust_helper_synchronize_srcu_expedited(struct srcu_struct *ssp)
+{
+	synchronize_srcu_expedited(ssp);
+}
-- 
2.51.2

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Gary Guo]

On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> Add helper wrappers for SRCU functions that are exposed to Rust
> through generated bindings.
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Onur Özkan <work@onurozkan.dev>
> ---
>  include/linux/srcu.h   |  5 +++++
>  rust/helpers/helpers.c |  1 +
>  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 36 insertions(+)
>  create mode 100644 rust/helpers/srcu.c
>
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index 81b1938512d5..790a4ef713c0 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
>  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
>  
>  int init_srcu_struct(struct srcu_struct *ssp);
> +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
> +				     struct lock_class_key *key)
> +{
> +	return init_srcu_struct(ssp);
> +}


This looks like a different strategy than, say, how mutex handles lockdep. IMO
the way that mutex handles this is more clear.

If we follow the way mutex is handles this, the `init_srcu_struct` would always
create lock class key and forward to `__init_srcu_struct`, and
`__init_srcu_struct` is an inline function that either calls
`init_srcu_struct_lockdep` with all args, or discard name/key and forward to
`init_srcu_struct_mutex`.

This is beneficial because the usage flows one way. You don't have in one config
`init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
config, which I think can be quite confusing.

Best,
Gary

>  #ifndef CONFIG_TINY_SRCU
>  int init_srcu_struct_fast(struct srcu_struct *ssp);
>  int init_srcu_struct_fast_updown(struct srcu_struct *ssp);
> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> index 625921e27dfb..f3562d3b3888 100644
> --- a/rust/helpers/helpers.c
> +++ b/rust/helpers/helpers.c
> @@ -88,6 +88,7 @@
>  #include "signal.c"
>  #include "slab.c"
>  #include "spinlock.c"
> +#include "srcu.c"
>  #include "sync.c"
>  #include "task.c"
>  #include "time.c"
> diff --git a/rust/helpers/srcu.c b/rust/helpers/srcu.c
> new file mode 100644
> index 000000000000..225b3bf9334a
> --- /dev/null
> +++ b/rust/helpers/srcu.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/srcu.h>
> +
> +__rust_helper int rust_helper_init_srcu_struct_with_key(struct srcu_struct *ssp,
> +							const char *name,
> +							struct lock_class_key *key)
> +{
> +	return __init_srcu_struct(ssp, name, key);
> +}
> +
> +__rust_helper int rust_helper_srcu_read_lock(struct srcu_struct *ssp)
> +{
> +	return srcu_read_lock(ssp);
> +}
> +
> +__rust_helper void rust_helper_srcu_read_unlock(struct srcu_struct *ssp, int idx)
> +{
> +	srcu_read_unlock(ssp, idx);
> +}
> +
> +__rust_helper void rust_helper_srcu_barrier(struct srcu_struct *ssp)
> +{
> +	srcu_barrier(ssp);
> +}
> +
> +__rust_helper void rust_helper_synchronize_srcu_expedited(struct srcu_struct *ssp)
> +{
> +	synchronize_srcu_expedited(ssp);
> +}

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Onur Özkan]

On Fri, 29 May 2026 12:58:17 +0100
Gary Guo <gary@garyguo.net> wrote:

> On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> > Add helper wrappers for SRCU functions that are exposed to Rust
> > through generated bindings.
> >
> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> > ---
> >  include/linux/srcu.h   |  5 +++++
> >  rust/helpers/helpers.c |  1 +
> >  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
> >  3 files changed, 36 insertions(+)
> >  create mode 100644 rust/helpers/srcu.c
> >
> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> > index 81b1938512d5..790a4ef713c0 100644
> > --- a/include/linux/srcu.h
> > +++ b/include/linux/srcu.h
> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
> >  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >  
> >  int init_srcu_struct(struct srcu_struct *ssp);
> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
> > +				     struct lock_class_key *key)
> > +{
> > +	return init_srcu_struct(ssp);
> > +}
> 
> 
> This looks like a different strategy than, say, how mutex handles lockdep. IMO
> the way that mutex handles this is more clear.

Initially it was the same strategy, this one was suggested by Paul [1] and it
didn't sound like a bad idea to me. Also, in previous revisions, Boqun once
said:

	"Having a "#ifdef" in a function body is generally considered as bad code
	(I know we have some of these in rust helpers, but helpers are a bit
	special and maybe we should clean them up). So could you move this
	function into include/linux/srcutiny.h and include/linux/srcutree.h?"

So putting them together, I decided to follow Paul's suggestion.

[1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@paulmck-laptop

> 
> If we follow the way mutex is handles this, the `init_srcu_struct` would always
> create lock class key and forward to `__init_srcu_struct`, and
> `__init_srcu_struct` is an inline function that either calls
> `init_srcu_struct_lockdep` with all args, or discard name/key and forward to
> `init_srcu_struct_mutex`.
> 
> This is beneficial because the usage flows one way. You don't have in one config
> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
> config, which I think can be quite confusing.
> 
> Best,
> Gary
> 
> >  #ifndef CONFIG_TINY_SRCU
> >  int init_srcu_struct_fast(struct srcu_struct *ssp);
> >  int init_srcu_struct_fast_updown(struct srcu_struct *ssp);
> > diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> > index 625921e27dfb..f3562d3b3888 100644
> > --- a/rust/helpers/helpers.c
> > +++ b/rust/helpers/helpers.c
> > @@ -88,6 +88,7 @@
> >  #include "signal.c"
> >  #include "slab.c"
> >  #include "spinlock.c"
> > +#include "srcu.c"
> >  #include "sync.c"
> >  #include "task.c"
> >  #include "time.c"
> > diff --git a/rust/helpers/srcu.c b/rust/helpers/srcu.c
> > new file mode 100644
> > index 000000000000..225b3bf9334a
> > --- /dev/null
> > +++ b/rust/helpers/srcu.c
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <linux/srcu.h>
> > +
> > +__rust_helper int rust_helper_init_srcu_struct_with_key(struct srcu_struct *ssp,
> > +							const char *name,
> > +							struct lock_class_key *key)
> > +{
> > +	return __init_srcu_struct(ssp, name, key);
> > +}
> > +
> > +__rust_helper int rust_helper_srcu_read_lock(struct srcu_struct *ssp)
> > +{
> > +	return srcu_read_lock(ssp);
> > +}
> > +
> > +__rust_helper void rust_helper_srcu_read_unlock(struct srcu_struct *ssp, int idx)
> > +{
> > +	srcu_read_unlock(ssp, idx);
> > +}
> > +
> > +__rust_helper void rust_helper_srcu_barrier(struct srcu_struct *ssp)
> > +{
> > +	srcu_barrier(ssp);
> > +}
> > +
> > +__rust_helper void rust_helper_synchronize_srcu_expedited(struct srcu_struct *ssp)
> > +{
> > +	synchronize_srcu_expedited(ssp);
> > +}
> 
> 

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Gary Guo]

On Fri May 29, 2026 at 1:07 PM BST, Onur Özkan wrote:
> On Fri, 29 May 2026 12:58:17 +0100
> Gary Guo <gary@garyguo.net> wrote:
>
>> On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
>> > Add helper wrappers for SRCU functions that are exposed to Rust
>> > through generated bindings.
>> >
>> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
>> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
>> > ---
>> >  include/linux/srcu.h   |  5 +++++
>> >  rust/helpers/helpers.c |  1 +
>> >  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
>> >  3 files changed, 36 insertions(+)
>> >  create mode 100644 rust/helpers/srcu.c
>> >
>> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
>> > index 81b1938512d5..790a4ef713c0 100644
>> > --- a/include/linux/srcu.h
>> > +++ b/include/linux/srcu.h
>> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
>> >  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
>> >  
>> >  int init_srcu_struct(struct srcu_struct *ssp);
>> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
>> > +				     struct lock_class_key *key)
>> > +{
>> > +	return init_srcu_struct(ssp);
>> > +}
>> 
>> 
>> This looks like a different strategy than, say, how mutex handles lockdep. IMO
>> the way that mutex handles this is more clear.
>
> Initially it was the same strategy, this one was suggested by Paul [1] and it
> didn't sound like a bad idea to me. Also, in previous revisions, Boqun once
> said:

I'm talking about changing how this is handled in SRCU side, not helper side.

>
> 	"Having a "#ifdef" in a function body is generally considered as bad code
> 	(I know we have some of these in rust helpers, but helpers are a bit
> 	special and maybe we should clean them up). So could you move this
> 	function into include/linux/srcutiny.h and include/linux/srcutree.h?"

mutex.h doesn't use ifdef inside function body, it just define two static inline
functions with the same signature in different ifdef branches.

Best,
Gary

>
> So putting them together, I decided to follow Paul's suggestion.
>
> [1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@paulmck-laptop
>
>> 
>> If we follow the way mutex is handles this, the `init_srcu_struct` would always
>> create lock class key and forward to `__init_srcu_struct`, and
>> `__init_srcu_struct` is an inline function that either calls
>> `init_srcu_struct_lockdep` with all args, or discard name/key and forward to
>> `init_srcu_struct_mutex`.
>> 
>> This is beneficial because the usage flows one way. You don't have in one config
>> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
>> config, which I think can be quite confusing.

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Onur Özkan]

On Fri, 29 May 2026 13:16:17 +0100
Gary Guo <gary@garyguo.net> wrote:

> On Fri May 29, 2026 at 1:07 PM BST, Onur Özkan wrote:
> > On Fri, 29 May 2026 12:58:17 +0100
> > Gary Guo <gary@garyguo.net> wrote:
> >
> >> On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> >> > Add helper wrappers for SRCU functions that are exposed to Rust
> >> > through generated bindings.
> >> >
> >> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> >> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> >> > ---
> >> >  include/linux/srcu.h   |  5 +++++
> >> >  rust/helpers/helpers.c |  1 +
> >> >  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
> >> >  3 files changed, 36 insertions(+)
> >> >  create mode 100644 rust/helpers/srcu.c
> >> >
> >> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> >> > index 81b1938512d5..790a4ef713c0 100644
> >> > --- a/include/linux/srcu.h
> >> > +++ b/include/linux/srcu.h
> >> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
> >> >  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >> >  
> >> >  int init_srcu_struct(struct srcu_struct *ssp);
> >> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
> >> > +				     struct lock_class_key *key)
> >> > +{
> >> > +	return init_srcu_struct(ssp);
> >> > +}
> >> 
> >> 
> >> This looks like a different strategy than, say, how mutex handles lockdep. IMO
> >> the way that mutex handles this is more clear.
> >
> > Initially it was the same strategy, this one was suggested by Paul [1] and it
> > didn't sound like a bad idea to me. Also, in previous revisions, Boqun once
> > said:
> 
> I'm talking about changing how this is handled in SRCU side, not helper side.
> 
> >
> > 	"Having a "#ifdef" in a function body is generally considered as bad code
> > 	(I know we have some of these in rust helpers, but helpers are a bit
> > 	special and maybe we should clean them up). So could you move this
> > 	function into include/linux/srcutiny.h and include/linux/srcutree.h?"
> 
> mutex.h doesn't use ifdef inside function body, it just define two static inline
> functions with the same signature in different ifdef branches.
> 

I might have confused them, let me check them again.

Thanks,
Onur

> Best,
> Gary
> 
> >
> > So putting them together, I decided to follow Paul's suggestion.
> >
> > [1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@paulmck-laptop
> >
> >> 
> >> If we follow the way mutex is handles this, the `init_srcu_struct` would always
> >> create lock class key and forward to `__init_srcu_struct`, and
> >> `__init_srcu_struct` is an inline function that either calls
> >> `init_srcu_struct_lockdep` with all args, or discard name/key and forward to
> >> `init_srcu_struct_mutex`.
> >> 
> >> This is beneficial because the usage flows one way. You don't have in one config
> >> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
> >> config, which I think can be quite confusing.

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Paul E. McKenney]

On Fri, May 29, 2026 at 01:16:17PM +0100, Gary Guo wrote:
> On Fri May 29, 2026 at 1:07 PM BST, Onur Özkan wrote:
> > On Fri, 29 May 2026 12:58:17 +0100
> > Gary Guo <gary@garyguo.net> wrote:
> >
> >> On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> >> > Add helper wrappers for SRCU functions that are exposed to Rust
> >> > through generated bindings.
> >> >
> >> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> >> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> >> > ---
> >> >  include/linux/srcu.h   |  5 +++++
> >> >  rust/helpers/helpers.c |  1 +
> >> >  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
> >> >  3 files changed, 36 insertions(+)
> >> >  create mode 100644 rust/helpers/srcu.c
> >> >
> >> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> >> > index 81b1938512d5..790a4ef713c0 100644
> >> > --- a/include/linux/srcu.h
> >> > +++ b/include/linux/srcu.h
> >> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
> >> >  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >> >  
> >> >  int init_srcu_struct(struct srcu_struct *ssp);
> >> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
> >> > +				     struct lock_class_key *key)
> >> > +{
> >> > +	return init_srcu_struct(ssp);
> >> > +}
> >> 
> >> 
> >> This looks like a different strategy than, say, how mutex handles lockdep. IMO
> >> the way that mutex handles this is more clear.
> >
> > Initially it was the same strategy, this one was suggested by Paul [1] and it
> > didn't sound like a bad idea to me. Also, in previous revisions, Boqun once
> > said:
> 
> I'm talking about changing how this is handled in SRCU side, not helper side.
> 
> >
> > 	"Having a "#ifdef" in a function body is generally considered as bad code
> > 	(I know we have some of these in rust helpers, but helpers are a bit
> > 	special and maybe we should clean them up). So could you move this
> > 	function into include/linux/srcutiny.h and include/linux/srcutree.h?"
> 
> mutex.h doesn't use ifdef inside function body, it just define two static inline
> functions with the same signature in different ifdef branches.

True, but SRCU has the added complication of having different !SMP (Tiny)
and SMP (Tree) implementations.  On the other hand, it is quite possible
that I missed a trick when setting up this part of SRCU.  Please feel
free to send a patch that simplifies it.

							Thanx, Paul

> Best,
> Gary
> 
> >
> > So putting them together, I decided to follow Paul's suggestion.
> >
> > [1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@paulmck-laptop
> >
> >> 
> >> If we follow the way mutex is handles this, the `init_srcu_struct` would always
> >> create lock class key and forward to `__init_srcu_struct`, and
> >> `__init_srcu_struct` is an inline function that either calls
> >> `init_srcu_struct_lockdep` with all args, or discard name/key and forward to
> >> `init_srcu_struct_mutex`.
> >> 
> >> This is beneficial because the usage flows one way. You don't have in one config
> >> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
> >> config, which I think can be quite confusing.
> 

Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers

[Onur Özkan]

On Sat, 30 May 2026 12:01:21 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> On Fri, May 29, 2026 at 01:16:17PM +0100, Gary Guo wrote:
> > On Fri May 29, 2026 at 1:07 PM BST, Onur Özkan wrote:
> > > On Fri, 29 May 2026 12:58:17 +0100
> > > Gary Guo <gary@garyguo.net> wrote:
> > >
> > >> On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> > >> > Add helper wrappers for SRCU functions that are exposed to Rust
> > >> > through generated bindings.
> > >> >
> > >> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> > >> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> > >> > ---
> > >> >  include/linux/srcu.h   |  5 +++++
> > >> >  rust/helpers/helpers.c |  1 +
> > >> >  rust/helpers/srcu.c    | 30 ++++++++++++++++++++++++++++++
> > >> >  3 files changed, 36 insertions(+)
> > >> >  create mode 100644 rust/helpers/srcu.c
> > >> >
> > >> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> > >> > index 81b1938512d5..790a4ef713c0 100644
> > >> > --- a/include/linux/srcu.h
> > >> > +++ b/include/linux/srcu.h
> > >> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_struct *ssp, const char *name,
> > >> >  #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> > >> >  
> > >> >  int init_srcu_struct(struct srcu_struct *ssp);
> > >> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const char *name,
> > >> > +				     struct lock_class_key *key)
> > >> > +{
> > >> > +	return init_srcu_struct(ssp);
> > >> > +}
> > >> 
> > >> 
> > >> This looks like a different strategy than, say, how mutex handles lockdep. IMO
> > >> the way that mutex handles this is more clear.
> > >
> > > Initially it was the same strategy, this one was suggested by Paul [1] and it
> > > didn't sound like a bad idea to me. Also, in previous revisions, Boqun once
> > > said:
> > 
> > I'm talking about changing how this is handled in SRCU side, not helper side.
> > 
> > >
> > > 	"Having a "#ifdef" in a function body is generally considered as bad code
> > > 	(I know we have some of these in rust helpers, but helpers are a bit
> > > 	special and maybe we should clean them up). So could you move this
> > > 	function into include/linux/srcutiny.h and include/linux/srcutree.h?"
> > 
> > mutex.h doesn't use ifdef inside function body, it just define two static inline
> > functions with the same signature in different ifdef branches.
> 
> True, but SRCU has the added complication of having different !SMP (Tiny)
> and SMP (Tree) implementations.  On the other hand, it is quite possible
> that I missed a trick when setting up this part of SRCU.  Please feel
> free to send a patch that simplifies it.

It's on the list [1].

Thanks,
Onur

[1]: https://lore.kernel.org/all/20260529134004.396743-2-work@onurozkan.dev

> 
> 							Thanx, Paul
> 
> > Best,
> > Gary
> > 
> > >
> > > So putting them together, I decided to follow Paul's suggestion.
> > >
> > > [1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@paulmck-laptop
> > >
> > >> 
> > >> If we follow the way mutex is handles this, the `init_srcu_struct` would always
> > >> create lock class key and forward to `__init_srcu_struct`, and
> > >> `__init_srcu_struct` is an inline function that either calls
> > >> `init_srcu_struct_lockdep` with all args, or discard name/key and forward to
> > >> `init_srcu_struct_mutex`.
> > >> 
> > >> This is beneficial because the usage flows one way. You don't have in one config
> > >> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in another
> > >> config, which I think can be quite confusing.
> > 

[PATCH v8 2/4] srcu: expose srcu_readers_active()

[Onur Özkan]

This is needed by rust/helpers/srcu.c which now adds
rust_helper_srcu_readers_active() as a wrapper around the SRCU helper
for Rust callers.

To achive this:

1- Move the srcu_readers_active() implementation from
   "kernel/rcu/srcutree.c" to "include/linux/srcutree.h".

2- Implement a matching srcu_readers_active() in
   "include/linux/srcutiny.h" and use it on the existing open-coded
   WARN_ON() check in cleanup_srcu_struct().

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 include/linux/srcutiny.h | 13 +++++++++++++
 include/linux/srcutree.h | 24 ++++++++++++++++++++++++
 kernel/rcu/srcutiny.c    |  2 +-
 kernel/rcu/srcutree.c    | 25 -------------------------
 rust/helpers/srcu.c      |  5 +++++
 5 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
index 905b629e8fa3..fbcf13bc12d1 100644
--- a/include/linux/srcutiny.h
+++ b/include/linux/srcutiny.h
@@ -154,4 +154,17 @@ static inline void srcu_torture_stats_print(struct srcu_struct *ssp,
 		 data_race(READ_ONCE(ssp->srcu_idx_max)));
 }
 
+/**
+ * srcu_readers_active - returns true if there are readers. and false otherwise.
+ * @ssp: which srcu_struct to count active readers (holding srcu_read_lock).
+ *
+ * Note that this is not an atomic primitive, and can therefore suffer
+ * severe errors when invoked on an active srcu_struct. That said, it
+ * can be useful as an error check at cleanup time.
+ */
+static inline bool srcu_readers_active(struct srcu_struct *ssp)
+{
+	return READ_ONCE(ssp->srcu_lock_nesting[0]) || READ_ONCE(ssp->srcu_lock_nesting[1]);
+}
+
 #endif
diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
index fd1a9270cb9a..75e54e4f963f 100644
--- a/include/linux/srcutree.h
+++ b/include/linux/srcutree.h
@@ -374,4 +374,28 @@ static inline void srcu_check_read_flavor(struct srcu_struct *ssp, int read_flav
 		__srcu_check_read_flavor(ssp, read_flavor);
 }
 
+/**
+ * srcu_readers_active - returns true if there are readers. and false otherwise.
+ * @ssp: which srcu_struct to count active readers (holding srcu_read_lock).
+ *
+ * Note that this is not an atomic primitive, and can therefore suffer
+ * severe errors when invoked on an active srcu_struct. That said, it
+ * can be useful as an error check at cleanup time.
+ */
+static inline bool srcu_readers_active(struct srcu_struct *ssp)
+{
+	int cpu;
+	unsigned long sum = 0;
+
+	for_each_possible_cpu(cpu) {
+		struct srcu_data *sdp = per_cpu_ptr(ssp->sda, cpu);
+
+		sum += atomic_long_read(&sdp->srcu_ctrs[0].srcu_locks);
+		sum += atomic_long_read(&sdp->srcu_ctrs[1].srcu_locks);
+		sum -= atomic_long_read(&sdp->srcu_ctrs[0].srcu_unlocks);
+		sum -= atomic_long_read(&sdp->srcu_ctrs[1].srcu_unlocks);
+	}
+	return sum;
+}
+
 #endif
diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
index a2e2d516e51b..5dc26af604bf 100644
--- a/kernel/rcu/srcutiny.c
+++ b/kernel/rcu/srcutiny.c
@@ -85,7 +85,7 @@ EXPORT_SYMBOL_GPL(init_srcu_struct);
  */
 void cleanup_srcu_struct(struct srcu_struct *ssp)
 {
-	WARN_ON(ssp->srcu_lock_nesting[0] || ssp->srcu_lock_nesting[1]);
+	WARN_ON(srcu_readers_active(ssp));
 	irq_work_sync(&ssp->srcu_irq_work);
 	flush_work(&ssp->srcu_work);
 	WARN_ON(ssp->srcu_gp_running);
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 0d01cd8c4b4a..b1e97ba2e53f 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -598,31 +598,6 @@ static bool srcu_readers_active_idx_check(struct srcu_struct *ssp, int idx)
 	return srcu_readers_lock_idx(ssp, idx, did_gp, unlocks);
 }
 
-/**
- * srcu_readers_active - returns true if there are readers. and false
- *                       otherwise
- * @ssp: which srcu_struct to count active readers (holding srcu_read_lock).
- *
- * Note that this is not an atomic primitive, and can therefore suffer
- * severe errors when invoked on an active srcu_struct.  That said, it
- * can be useful as an error check at cleanup time.
- */
-static bool srcu_readers_active(struct srcu_struct *ssp)
-{
-	int cpu;
-	unsigned long sum = 0;
-
-	for_each_possible_cpu(cpu) {
-		struct srcu_data *sdp = per_cpu_ptr(ssp->sda, cpu);
-
-		sum += atomic_long_read(&sdp->srcu_ctrs[0].srcu_locks);
-		sum += atomic_long_read(&sdp->srcu_ctrs[1].srcu_locks);
-		sum -= atomic_long_read(&sdp->srcu_ctrs[0].srcu_unlocks);
-		sum -= atomic_long_read(&sdp->srcu_ctrs[1].srcu_unlocks);
-	}
-	return sum;
-}
-
 /*
  * We use an adaptive strategy for synchronize_srcu() and especially for
  * synchronize_srcu_expedited().  We spin for a fixed time period
diff --git a/rust/helpers/srcu.c b/rust/helpers/srcu.c
index 225b3bf9334a..1a2f563640e0 100644
--- a/rust/helpers/srcu.c
+++ b/rust/helpers/srcu.c
@@ -9,6 +9,11 @@ __rust_helper int rust_helper_init_srcu_struct_with_key(struct srcu_struct *ssp,
 	return __init_srcu_struct(ssp, name, key);
 }
 
+__rust_helper bool rust_helper_srcu_readers_active(struct srcu_struct *ssp)
+{
+	return srcu_readers_active(ssp);
+}
+
 __rust_helper int rust_helper_srcu_read_lock(struct srcu_struct *ssp)
 {
 	return srcu_read_lock(ssp);
-- 
2.51.2

Re: [PATCH v8 2/4] srcu: expose srcu_readers_active()

[Gary Guo]

On Fri May 29, 2026 at 12:43 PM BST, Onur Özkan wrote:
> This is needed by rust/helpers/srcu.c which now adds
> rust_helper_srcu_readers_active() as a wrapper around the SRCU helper
> for Rust callers.
> 
> To achive this:
> 
> 1- Move the srcu_readers_active() implementation from
>    "kernel/rcu/srcutree.c" to "include/linux/srcutree.h".
> 
> 2- Implement a matching srcu_readers_active() in
>    "include/linux/srcutiny.h" and use it on the existing open-coded
>    WARN_ON() check in cleanup_srcu_struct().
> 
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Onur Özkan <work@onurozkan.dev>

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  include/linux/srcutiny.h | 13 +++++++++++++
>  include/linux/srcutree.h | 24 ++++++++++++++++++++++++
>  kernel/rcu/srcutiny.c    |  2 +-
>  kernel/rcu/srcutree.c    | 25 -------------------------
>  rust/helpers/srcu.c      |  5 +++++
>  5 files changed, 43 insertions(+), 26 deletions(-)

[PATCH v8 3/4] rust: sync: add SRCU abstraction

[Onur Özkan]

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`. It first checks for active read-side
sections and emits a warning if any guards were leaked. In that case, it
waits in `synchronize_srcu()` rather than risking a UAF by freeing the
`srcu_struct` that is still reachable from the C side. It then uses
`srcu_barrier()` to drain pending callbacks before finally calling
`cleanup_srcu_struct()`.

Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 rust/kernel/sync.rs      |   2 +
 rust/kernel/sync/srcu.rs | 173 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 175 insertions(+)
 create mode 100644 rust/kernel/sync/srcu.rs

diff --git a/rust/kernel/sync.rs b/rust/kernel/sync.rs
index 993dbf2caa0e..0d6a5f1300c3 100644
--- a/rust/kernel/sync.rs
+++ b/rust/kernel/sync.rs
@@ -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.
 ///
diff --git a/rust/kernel/sync/srcu.rs b/rust/kernel/sync/srcu.rs
new file mode 100644
index 000000000000..75d4029dae43
--- /dev/null
+++ b/rust/kernel/sync/srcu.rs
@@ -0,0 +1,173 @@
+// 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"
+            );
+
+            // `cleanup_srcu_struct()` may return early if there are still active readers.
+            // This should only happen if a guard was leaked with `mem::forget`, which is
+            // "WRONG" code and may cause a UAF because Rust will free the `srcu_struct`
+            // while it is still referenced from the C side (e.g. by `call_srcu()` callbacks).
+            //
+            // Another consequence of leaking guards is that `call_srcu()` callbacks will
+            // never run because the grace period can never complete due to permanently
+            // active readers (i.e. leaked guards).
+            //
+            // If this ever happens, that means the guard was leaked by mistake and the
+            // caller must fix the bug. Sleeping here is intentional and less harmful
+            // than risking a UAF.
+            //
+            // SAFETY: By the type invariants, `self` contains a valid and pinned
+            // `struct srcu_struct`.
+            unsafe { bindings::synchronize_srcu(ptr) };
+        }
+
+        // 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) };
+    }
+}
-- 
2.51.2

[PATCH v8 4/4] MAINTAINERS: add Rust SRCU files to SRCU entry

[Onur Özkan]

Include Rust side implementation files to the SRCU maintainer
entry.

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e0b307b2108c..7739a435f258 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24624,6 +24624,7 @@ SLEEPABLE READ-COPY UPDATE (SRCU)
 M:	Lai Jiangshan <jiangshanlai@gmail.com>
 M:	"Paul E. McKenney" <paulmck@kernel.org>
 M:	Josh Triplett <josh@joshtriplett.org>
+M:	Onur Özkan <work@onurozkan.dev> (RUST)
 R:	Steven Rostedt <rostedt@goodmis.org>
 R:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
 L:	rcu@vger.kernel.org
@@ -24632,6 +24633,8 @@ W:	http://www.rdrop.com/users/paulmck/RCU/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git rcu/dev
 F:	include/linux/srcu*.h
 F:	kernel/rcu/srcu*.c
+F:	rust/helpers/srcu.c
+F:	rust/kernel/sync/srcu.rs
 
 SMACK SECURITY MODULE
 M:	Casey Schaufler <casey@schaufler-ca.com>
-- 
2.51.2