From: Frederic Weisbecker <frederic@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
linux-kernel@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joelagnelf@nvidia.com>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang@linux.dev>,
Davidlohr Bueso <dave@stgolabs.net>,
Kunwu Chan <kunwu.chan@gmail.com>,
Puranjay Mohan <puranjay@kernel.org>,
rcu@vger.kernel.org, David Woodhouse <dwmw@amazon.co.uk>,
Kunwu Chan <chentao@kylinos.cn>
Subject: Re: [PATCH v3 1/7] srcutiny: Do not call synchronize_rcu() from synchronize_srcu_atomic()
Date: Thu, 12 Nov 2026 17:53:00 +0100 [thread overview]
Message-ID: <avXu7COBJungJynA@localhost.localdomain> (raw)
In-Reply-To: <20261112133731.127221-2-mathieu.desnoyers@efficios.com>
Le Thu, Nov 12, 2026 at 08:37:25AM -0500, Mathieu Desnoyers a écrit :
> synchronize_srcu_atomic() never blocks, so that it can be called from
> atomic context. This includes interrupt handlers, and code within
> rcu_read_lock().
>
> With CONFIG_PREEMPTION=y, the Tiny SRCU version first calls
> synchronize_rcu(). Tiny synchronize_rcu() does not wait: it only
> advances rcu_ctrlblk.gp_seq. This is valid where the caller is in a
> quiescent state, in task context and outside of any RCU reader.
>
> The callers of synchronize_srcu_atomic() need not be in a quiescent
> state. An interrupt handler may have interrupted an RCU reader. A
> caller within rcu_read_lock() is itself an RCU reader. In both cases,
> synchronize_rcu() ends an RCU grace period while an RCU reader is still
> in its critical section. poll_state_synchronize_rcu() would then
> report a grace period that did not happen. The caller within
> rcu_read_lock() also gets "Illegal synchronize_rcu() in RCU read-side
> critical section" from lockdep.
>
> srcu_drive_gp() has the same call. There, it makes an RCU Tasks
> Trace grace period imply an RCU grace period. RCU Tasks Trace uses
> call_srcu() and synchronize_srcu(), which are both forbidden on a
> srcu_struct that uses synchronize_srcu_atomic(). And the Tree SRCU
> version of synchronize_srcu_atomic() does not wait for an RCU grace
> period either.
>
> Fix this by removing the call.
>
> This was found by reading the code. An rcutorture test added later in
> this series fails without this change.
>
> Fixes: a48669f0c49c ("srcutiny: Add an atomic Tiny SRCU")
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Tested-by: David Woodhouse <dwmw@amazon.co.uk>
> Reviewed-by: Kunwu Chan <chentao@kylinos.cn>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2026-11-12 16:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 13:37 [PATCH v3 0/7] srcu: NMI-safe atomic SRCU readers, and their irqsave forms Mathieu Desnoyers
2026-11-12 13:37 ` [PATCH v3 1/7] srcutiny: Do not call synchronize_rcu() from synchronize_srcu_atomic() Mathieu Desnoyers
2026-11-12 16:53 ` Frederic Weisbecker [this message]
2026-11-12 13:37 ` [PATCH v3 2/7] srcu: Rule for using synchronize_srcu_atomic() from interrupt handlers Mathieu Desnoyers
2026-11-12 17:10 ` Frederic Weisbecker
2026-11-12 13:37 ` [PATCH v3 3/7] srcu: Make atomic SRCU readers NMI-safe Mathieu Desnoyers
2026-11-12 13:37 ` [PATCH v3 4/7] srcu: Add irqsave variants of the atomic SRCU readers Mathieu Desnoyers
2026-11-12 13:37 ` [PATCH v3 5/7] rcutorture: Run NMI-safe SRCU readers from NMI Mathieu Desnoyers
2026-11-12 13:37 ` [PATCH v3 6/7] rcutorture: Test the irqsave forms of atomic SRCU readers Mathieu Desnoyers
2026-11-12 13:37 ` [PATCH v3 7/7] rcutorture: Check an atomic SRCU wait within an RCU reader Mathieu Desnoyers
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=avXu7COBJungJynA@localhost.localdomain \
--to=frederic@kernel.org \
--cc=boqun@kernel.org \
--cc=chentao@kylinos.cn \
--cc=dave@stgolabs.net \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=jiangshanlai@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=josh@joshtriplett.org \
--cc=kunwu.chan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=puranjay@kernel.org \
--cc=qiang.zhang@linux.dev \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.com \
/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.