Re: [PATCH v10 4/5] rust: sync: add SRCU abstraction

[Alice Ryhl <aliceryhl@google.com>]

On Sat, Jun 13, 2026 at 09:40:10AM +0300, Onur Özkan wrote:
> +#[pinned_drop]
> +impl PinnedDrop for Srcu {
> +    fn drop(self: Pin<&mut Self>) {
> +        let ptr = self.inner.get();
> +
> +        if crate::warn_on!(
> +            // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
> +            // and `srcu_readers_active()` only checks the active reader count.
> +            unsafe { bindings::srcu_readers_active(ptr) }
> +        ) {
> +            // `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) };

Hmm. It's not entirely clear to me that synchronize_srcu() is needed
here. If there are calls to srcu_read_lock() that do not have a matching
unlock due to use of mem::forget(), then either there is a pending
call_srcu() callback in the queue, in which case srcu_barrier() already
sleeps forever, or there are no such callbacks in which case I don't
think this actually leads to UAF.

Thoughts?

Alice