mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


             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®