From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "Paul E . McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
David Woodhouse <dwmw2@infradead.org>,
Frederic Weisbecker <frederic@kernel.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
Subject: [PATCH v2 0/7] srcu: NMI-safe atomic SRCU readers, and their irqsave forms
Date: Wed, 11 Nov 2026 09:59:42 -0500 [thread overview]
Message-ID: <20261111145949.70845-1-mathieu.desnoyers@efficios.com> (raw)
Hi Paul,
This series adapts atomic SRCU to the needs of RCU pseudo-transactions
[1], as we discussed [2]. Their readers resolve a proxy within a short
section, in any context, NMI included. A writer waits for these
sections without sleeping, from task, softirq or hardirq context.
Atomic SRCU fits, with one fix, one rule made explicit and two
additions:
- Patch 1 fixes Tiny synchronize_srcu_atomic(). With
CONFIG_PREEMPTION=y, it called synchronize_rcu(), which ends an RCU
grace period on Tiny RCU. That is wrong when the caller is in an
interrupt handler or within rcu_read_lock().
- Patch 2 is about calling synchronize_srcu_atomic() from an interrupt
handler. All calls on that srcu_struct, task context included, must
then disable interrupts around it. Otherwise, the interrupt handler
may spin forever on the CPU of a waiter it interrupted. Patch 2
documents this rule, and warns when it is broken.
- Patch 3 makes the atomic readers NMI-safe. They use the counter
increments of __srcu_read_lock_nmisafe(), which keep the full barriers
that synchronize_srcu_atomic() pairs with.
- Patch 4 adds srcu_read_lock_atomic_irqsave() and
srcu_read_unlock_atomic_irqrestore(). They disable interrupts instead
of preemption, for a domain whose writers wait with interrupts
disabled.
- Patch 5 makes rcutorture run readers from NMI, for the NMI-safe reader
flavors.
- Patch 6 makes rcutorture alternate the atomic readers of each CPU with
irqsave readers, with a new atomic_irqsave parameter. It also adds an
SRCU-P run of this mode to torture.sh.
- Patch 7 makes rcutorture check what patch 1 fixes.
Patch 2 does not make synchronize_srcu_atomic() disable interrupts
itself. A reader that disables only preemption may wait for an IPI to
the waiter's CPU, and that IPI would never run. Only the caller knows
that its readers disable interrupts.
On architectures without NMI-safe this_cpu_inc(), every atomic reader
now pays an atomic increment at lock and at unlock. The update side is
unchanged. On architectures with NMI-safe this_cpu_inc(), such as x86,
the readers use the same counter increments as before. David agreed to
the change, as long as synchronize_srcu_atomic() stays within the 4-16us
it was designed for [3].
Changes since v1 [4]
--------------------
- Rebased on v7.4-rc2. Patch 5 (v1 patch 3) no longer applied,
because of the kzalloc_objs() conversion in rcutorture.
- New patches 1 and 7, the Tiny SRCU fix above and its test. Paul,
please check that nothing needs an atomic SRCU grace period to imply
an RCU grace period. Tree SRCU never provided that.
- New patch 2, the rule above. A prototype KUnit test of RCU
pseudo-transactions hit the hang: it waits from a task, and from an
IPI on the same CPU. RCU pseudo-transactions now disable interrupts
around their wait.
- Patch 5 (v1 patch 3), after your review: the readers in NMI count
their pipe and batch values in atomic arrays of their own. The
statistics print them as "NMI Reader Pipe:" and "NMI Reader Batch:".
A too-short grace period seen in NMI now gets "!!!" and a warning.
- Patch 6 (v1 patch 4), after your review:
- the atomic_irqsave description says that the readers alternate per
CPU, which also holds for a single reader;
- SRCU_TORTURE_IRQSAVE is 0x80, defined next to RCUTORTURE_RDR_MASK_1
and _2;
- the irqsave readers run only when ->extendables is zero, instead of
clearing extendables.
Testing
-------
Testing was on x86_64 under QEMU/KVM, with
CONFIG_FORCE_NEED_SRCU_NMI_SAFE=y:
- SRCU-P with atomic readers alternating with irqsave readers, for 5
minutes: no error. It ran 40876 grace periods and 94824 readers in
NMI. The same without irqsave readers, for 2 minutes: no error.
- SRCU-P with the NMI-safe reader flavor, then with the fast one, for 2
minutes each: no error. Both ran readers in NMI.
- SRCU-T (Tiny SRCU) with atomic and irqsave readers, for 2 minutes: no
error.
- The srcu_lockdep.sh cases of synchronize_srcu_atomic() give their
expected results. A wait within rcu_read_lock() (61 to 63) gets no
lockdep warning. A reader that ran with interrupts enabled, then a
wait from an IPI (1071 to 1073), still gets
"inconsistent {HARDIRQ-ON-R}".
- A throwaway KUnit test waits from an IPI on the CPU of a waiter in
task context. The new check warns, then the wait hangs, as the rule
says it must. With every caller disabling interrupts, the same test
passes.
Each new check fails when what it checks is broken:
- A reader's counter update is split in two, with an NMI reader in
between: the writer stalls in its grace period.
- The flavor check rejects atomic readers in NMI: it warns.
- An irqsave unlock restores interrupts while another irqsave reader of
its CPU is held: the new check in rcutorture warns.
- Every reader in NMI sees a pipe count of 2: rcutorture prints "!!!"
and warns of a too-short grace period in NMI.
- Patch 1 is reverted, on SRCU-T: the check of patch 7 warns. lockdep
also reports "Illegal synchronize_rcu() in RCU read-side critical
section".
The readers in NMI need a PMU in the guest. kvm.sh starts x86 guests
with -cpu kvm64, which has none. So these runs added --qemu-args
"-cpu host,pmu=on". Without it, rcutorture reports that NMIs went
untested. This also holds for the existing test of ->call() from NMI.
This series was developed with assistance from an LLM. I reviewed the
code and the tests.
The series is based on v7.4-rc2.
[1] https://lore.kernel.org/all/20261016133319.433617-1-mathieu.desnoyers@efficios.com/
[2] https://lore.kernel.org/all/853d8469-94a4-4b33-a0d5-d6d2138fe3ef@paulmck-laptop/
[3] https://lore.kernel.org/all/84fdca577207092bd16fc8f3949c9b7a776750ba.camel@infradead.org/
[4] https://lore.kernel.org/all/20261110192844.44713-1-mathieu.desnoyers@efficios.com/
Thanks,
Mathieu
Mathieu Desnoyers (7):
srcutiny: Do not call synchronize_rcu() from synchronize_srcu_atomic()
srcu: Rule for using synchronize_srcu_atomic() from interrupt handlers
srcu: Make atomic SRCU readers NMI-safe
srcu: Add irqsave variants of the atomic SRCU readers
rcutorture: Run NMI-safe SRCU readers from NMI
rcutorture: Test the irqsave forms of atomic SRCU readers
rcutorture: Check an atomic SRCU wait within an RCU reader
include/linux/srcu.h | 108 +++++++---
kernel/rcu/rcutorture.c | 197 +++++++++++++++++-
kernel/rcu/srcutiny.c | 7 +-
kernel/rcu/srcutree.c | 18 +-
.../selftests/rcutorture/bin/torture.sh | 6 +
5 files changed, 296 insertions(+), 40 deletions(-)
base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
--
2.47.3
next reply other threads:[~2026-11-11 14:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 14:59 Mathieu Desnoyers [this message]
2026-11-11 14:59 ` [PATCH v2 1/7] srcutiny: Do not call synchronize_rcu() from synchronize_srcu_atomic() Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 2/7] srcu: Rule for using synchronize_srcu_atomic() from interrupt handlers Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 3/7] srcu: Make atomic SRCU readers NMI-safe Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 4/7] srcu: Add irqsave variants of the atomic SRCU readers Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 5/7] rcutorture: Run NMI-safe SRCU readers from NMI Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 6/7] rcutorture: Test the irqsave forms of atomic SRCU readers Mathieu Desnoyers
2026-11-11 14:59 ` [PATCH v2 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=20261111145949.70845-1-mathieu.desnoyers@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun@kernel.org \
--cc=dave@stgolabs.net \
--cc=dwmw2@infradead.org \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=josh@joshtriplett.org \
--cc=kunwu.chan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®