From: sashiko-bot@kernel.org
To: "Philipp Stanner" <phasta@kernel.org>
Cc: dri-devel@lists.freedesktop.org, ojeda@kernel.org
Subject: Re: [PATCH v5 3/5] rust: sync: Add abstraction for rcu_barrier()
Date: Fri, 03 Jul 2026 07:40:45 +0000 [thread overview]
Message-ID: <20260703074047.21FCB1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260703073141.3962604-5-phasta@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The function name `rcu_barrier` causes module-level stuttering (`rcu::rcu_barrier()`).
--
commit 7b2bfcaf9137cfae11ac6cf2b69d559a4e731460
Author: Philipp Stanner <phasta@kernel.org>
rust: sync: Add abstraction for rcu_barrier()
This commit adds a safe Rust abstraction for the C function rcu_barrier(),
which waits for all in-flight call_rcu() callbacks to complete.
> diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
> index a32bef6e490b0..7031ca5d24738 100644
> --- a/rust/kernel/sync/rcu.rs
> +++ b/rust/kernel/sync/rcu.rs
[ ... ]
> @@ -50,3 +50,23 @@ fn drop(&mut self) {
> pub fn read_lock() -> Guard {
> Guard::new()
> }
> +
> +/// Wait until all in-flight call_rcu() callbacks complete.
> +///
> +/// Note that this primitive does not necessarily wait for an RCU grace period
> +/// to complete. For example, if there are no RCU callbacks queued anywhere
> +/// in the system, then rcu_barrier() is within its rights to return
> +/// immediately, without waiting for anything, much less an RCU grace period.
> +/// In fact, rcu_barrier() will normally not result in any RCU grace periods
> +/// beyond those that were already destined to be executed.
> +///
> +/// In kernels built with CONFIG_RCU_LAZY=y, this function also hurries all
> +/// pending lazy RCU callbacks.
> +///
> +/// Note that this is one of the RCU primitives which must not be called in
> +/// atomic context.
> +#[inline]
> +pub fn rcu_barrier() {
[Severity: Low]
This isn't a bug, but naming this function rcu_barrier() inside the rcu
module leads to stuttering when called (i.e., rcu::rcu_barrier()). Would it
be better to name this simply barrier() so it can be called as
rcu::barrier(), similar to how rcu_read_lock() is exposed as
rcu::read_lock()?
> + // SAFETY: `rcu_barrier()` is always safe to be called. It just might wait for a grace period.
> + unsafe { bindings::rcu_barrier() };
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703073141.3962604-2-phasta@kernel.org?part=3
next prev parent reply other threads:[~2026-07-03 7:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 7:31 [PATCH v5 0/5] rust / dma_buf: Add abstractions for dma_fence Philipp Stanner
2026-07-03 7:31 ` [PATCH v5 1/5] rust: types: implement ForeignOwnable for ARef<T> Philipp Stanner
2026-07-03 7:42 ` sashiko-bot
2026-07-03 7:31 ` [PATCH v5 2/5] rust: error: Add ECANCELED error code Philipp Stanner
2026-07-03 7:31 ` [PATCH v5 3/5] rust: sync: Add abstraction for rcu_barrier() Philipp Stanner
2026-07-03 7:40 ` sashiko-bot [this message]
2026-07-03 7:31 ` [PATCH v5 4/5] rust: Add dma_fence abstractions Philipp Stanner
2026-07-03 7:45 ` sashiko-bot
2026-07-08 13:29 ` Philipp Stanner
2026-07-03 7:31 ` [PATCH v5 5/5] MAINTAINERS: Add entry for Rust dma-buf Philipp Stanner
2026-07-06 13:07 ` [PATCH v5 0/5] rust / dma_buf: Add abstractions for dma_fence Daniel Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260703074047.21FCB1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=phasta@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.