From: Kunwu Chan <kunwu.chan@gmail.com>
To: paulmck@kernel.org, jiangshanlai@gmail.com, josh@joshtriplett.org
Cc: rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
Kunwu Chan <kunwu.chan@gmail.com>
Subject: [PATCH 02/13] litmus: Add SRCU fastpath scan-before-anchor test
Date: Mon, 7 Sep 2026 15:58:18 +0800 [thread overview]
Message-ID: <20260907075829.2073224-3-kunwu.chan@linux.dev> (raw)
In-Reply-To: <20260907075829.2073224-1-kunwu.chan@linux.dev>
From: Kunwu Chan <kunwu.chan@gmail.com>
If the synchronize_srcu_atomic() fastpath instead places its lock scan
before the grace-period anchor, the scan can miss a reader whose
increment was already visible before the anchor. That reader already
existed when the grace period started, so completing the grace period
without waiting for it would violate the SRCU grace-period guarantee.
This litmus test models the reversed ordering, with the lock scan placed
before the grace-period anchor. "seq" models the grace-period anchor in
->srcu_gp_seq and "ctr" models the per-CPU ->srcu_ctrs[].srcu_locks
counter. P0 scans the lock counter before writing the anchor, with an
smp_mb() between them. P1 models the reader-side counter increment,
with the smp_mb() of __srcu_read_lock() following the increment. P2
models an observer that sees the reader's increment before seeing the
anchor.
The same outcome is allowed with this ordering, and herd7 reports
"Sometimes". The litmus-tests README is also updated to describe both
SRCU fastpath tests.
Tested with herd7 7.58 using linux-kernel.cfg.
Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
---
tools/memory-model/litmus-tests/README | 16 ++++++
.../SRCU-fastpath-scan-before-anchor.litmus | 53 +++++++++++++++++++
2 files changed, 69 insertions(+)
create mode 100644 tools/memory-model/litmus-tests/SRCU-fastpath-scan-before-anchor.litmus
diff --git a/tools/memory-model/litmus-tests/README b/tools/memory-model/litmus-tests/README
index d311a0ff1ae6..449747c6db9e 100644
--- a/tools/memory-model/litmus-tests/README
+++ b/tools/memory-model/litmus-tests/README
@@ -137,6 +137,22 @@ S+fencewmbonceonce+poacquireonce.litmus
Can a smp_wmb(), instead of a release, and an acquire order
a prior store against a subsequent store?
+SRCU-fastpath-anchor-before-scan.litmus
+ This models the synchronize_srcu_atomic() fastpath with the
+ grace-period anchor ordered before the lock-counter scan. This
+ ordering prevents readers that existed before the grace period
+ from being missed by the scan. See
+ SRCU-fastpath-scan-before-anchor.litmus for the reversed
+ ordering.
+
+SRCU-fastpath-scan-before-anchor.litmus
+ This models the synchronize_srcu_atomic() fastpath with the
+ lock-counter scan ordered before the grace-period anchor. This
+ permits the scan to miss readers that existed before the grace
+ period, violating the SRCU grace-period guarantee. See
+ SRCU-fastpath-anchor-before-scan.litmus for the opposite
+ ordering.
+
WRC+poonceonces+Once.litmus
WRC+pooncerelease+fencermbonceonce+Once.litmus
These two are members of an extension of the MP litmus-test
diff --git a/tools/memory-model/litmus-tests/SRCU-fastpath-scan-before-anchor.litmus b/tools/memory-model/litmus-tests/SRCU-fastpath-scan-before-anchor.litmus
new file mode 100644
index 000000000000..931a41014de7
--- /dev/null
+++ b/tools/memory-model/litmus-tests/SRCU-fastpath-scan-before-anchor.litmus
@@ -0,0 +1,53 @@
+C SRCU-fastpath-scan-before-anchor
+
+(*
+ * Result: Sometimes
+ *
+ * If the synchronize_srcu_atomic() fastpath instead places its lock
+ * scan before the grace-period anchor, the scan can miss a reader whose
+ * increment was already visible before the anchor. That reader already
+ * existed when the grace period started, so completing the grace period
+ * without waiting for it would violate the SRCU grace-period guarantee.
+ *
+ * This litmus test models the reversed ordering, with the lock scan
+ * placed before the grace-period anchor. "seq" models the grace-period
+ * anchor in ->srcu_gp_seq and "ctr" models the per-CPU
+ * ->srcu_ctrs[].srcu_locks counter. P0 scans the lock counter before
+ * writing the anchor, with an smp_mb() between them. P1 models the
+ * reader-side counter increment, with the smp_mb() of __srcu_read_lock()
+ * following the increment. P2 models an observer that sees the reader's
+ * increment before seeing the anchor.
+ *
+ * The same outcome is allowed with this ordering, and herd7 reports
+ * "Sometimes". See SRCU-fastpath-anchor-before-scan.litmus for the
+ * opposite ordering, which forbids this outcome.
+ *)
+
+{}
+
+P0(int *seq, int *ctr)
+{
+ int r2;
+
+ r2 = READ_ONCE(*ctr);
+ smp_mb();
+ WRITE_ONCE(*seq, 1);
+}
+
+P1(int *ctr)
+{
+ WRITE_ONCE(*ctr, 1);
+ smp_mb();
+}
+
+P2(int *seq, int *ctr)
+{
+ int r3;
+ int r4;
+
+ r3 = READ_ONCE(*ctr);
+ smp_mb();
+ r4 = READ_ONCE(*seq);
+}
+
+exists (0:r2 = 0 /\ 2:r3 = 1 /\ 2:r4 = 0)
--
2.43.0
next prev parent reply other threads:[~2026-09-07 7:58 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 7:58 [PATCH 00/13] srcu: Round out atomic SRCU support Kunwu Chan
2026-09-07 7:58 ` [PATCH 01/13] litmus: Add SRCU fastpath anchor-before-scan test Kunwu Chan
2026-09-08 23:58 ` Paul E. McKenney
2026-09-09 3:02 ` Kunwu Chan
2026-09-07 7:58 ` Kunwu Chan [this message]
2026-09-07 7:58 ` [PATCH 03/13] srcutree: Add reader-free fastpath to synchronize_srcu_atomic() Kunwu Chan
2026-09-08 20:29 ` Paul E. McKenney
2026-09-08 21:13 ` David Woodhouse
2026-09-08 21:54 ` Paul E. McKenney
2026-09-08 22:09 ` David Woodhouse
2026-09-08 22:55 ` Paul E. McKenney
2026-09-08 22:26 ` David Woodhouse
2026-09-08 22:53 ` Paul E. McKenney
2026-09-08 22:56 ` David Woodhouse
2026-09-08 23:34 ` Paul E. McKenney
2026-09-09 3:35 ` Kunwu Chan
2026-09-07 7:58 ` [PATCH 04/13] rcutorture: Add atomic-SRCU support to torture.sh Kunwu Chan
2026-09-08 23:34 ` Paul E. McKenney
2026-09-09 22:35 ` Paul E. McKenney
2026-09-10 1:30 ` KunWu Chan
2026-09-10 3:47 ` Paul E. McKenney
2026-09-10 4:31 ` KunWu Chan
2026-09-07 7:58 ` [PATCH 05/13] srcutree: Honor is_atomic in check_init_srcu_struct() Kunwu Chan
2026-09-08 20:27 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 06/13] srcutree: Make init_srcu_struct_atomic() prevent transition to big Kunwu Chan
2026-09-08 23:36 ` Paul E. McKenney
2026-09-09 2:34 ` Kunwu Chan
2026-09-10 0:08 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 07/13] srcutree: Don't transition atomic SRCU to big in srcu_gp_end() Kunwu Chan
2026-09-08 23:38 ` Paul E. McKenney
2026-09-09 2:45 ` Kunwu Chan
2026-09-10 0:13 ` Paul E. McKenney
2026-09-10 3:18 ` KunWu Chan
2026-09-10 3:46 ` Paul E. McKenney
2026-09-10 4:27 ` KunWu Chan
2026-09-07 7:58 ` [PATCH 08/13] srcutree: Forbid srcu_expedite_current() on atomic SRCU Kunwu Chan
2026-09-08 23:43 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 09/13] rcutorture: Disable srcu_expedite_current() for " Kunwu Chan
2026-09-08 23:48 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 10/13] srcutree: Skip callback scheduling for atomic SRCU grace periods Kunwu Chan
2026-09-09 0:01 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 11/13] srcutree: Remove srcu_barrier() sleep for atomic SRCU Kunwu Chan
2026-09-09 0:05 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 12/13] srcutree: Remove debug pr_alert()s Kunwu Chan
2026-09-09 0:06 ` Paul E. McKenney
2026-09-07 7:58 ` [PATCH 13/13] srcu: Restrict atomic-SRCU non_block annotation to task context Kunwu Chan
2026-09-09 0:11 ` Paul E. McKenney
2026-09-10 12:16 ` [PATCH 00/13] srcu: Round out atomic SRCU support Zqiang
2026-09-11 2:31 ` KunWu Chan
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=20260907075829.2073224-3-kunwu.chan@linux.dev \
--to=kunwu.chan@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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®