From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794531474; b=WtTOebMKDhnzXMePKf2/BTc7NJaAubW7L0nxi105bHDX4nGr0NFM2UXvwgvj4NBwe5BM 5ZOJXtMfOIMHX1ftPpZBHHbcBGjnplkzsJEV5BsPZPmCQ+QXo6OQie2ygWO0Cmh6Ij7cK hA4H1NgXXP/j29d+oWIb1MG01JeaLkftC+6YGmVE9hJyE0fO8fbE5CB871QJwrXSXFZej PAa74QeBduLNbeGJaCP0itkoA6okHnT6MWLVk1n6fkz+bitp97g86VH1W1bmZIukwUrop m9+IvnOCdZrVbsYa9YG8L64StUDkPRJlMOt+D81H21Q9On/3lWgpGt2AtjaCfZ1O8vQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794531474; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=OcfSVkWao6pdjVtwXUlio7NDEQODdtBQ2I49ki3ouiQ=; b=tmH/e8uyqO3pPcMQyij38fhC6k3pMEWN5BaaLG3JN4Tv6KZnsgBrzi00ZNwiootJlFMG mxtHLhk4Mln9R8brONXteI4y1Xnv9FwFrpAhq2rIyBCDoSeLvibANbiy6120ZNxwoRO4b J0VXPClW+BFI5j9SnGZ3eylmgOvstZEQB8hNAv5zFqICFCmoPUH1JjdZ11RhAe1LcBk9v o+LlcqnO8OzvO42iEj0vpOKFZMz0UULcwq4Cd/iOrSRwCb8JkUXNZ5yYZsyQIQW2n+IMQ Yo6zIdpZtH6tgfqsYumYZGO3amgCSD5CD7PVhcpEya3UlLsEE+xlcfz1NF+JPuuiUIg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Yck2E+XZ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with UTF8SMTPS id 7372F606A88C; Fri, 13 Nov 2026 00:57:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Yck2E+XZ Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 0407F1F000C8; Fri, 13 Nov 2026 00:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794531474; bh=OcfSVkWao6pdjVtwXUlio7NDEQODdtBQ2I49ki3ouiQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Yck2E+XZD2a+MPTzefi/1pfLD6NZuHf1ey/lRUeQ4c/2CXFjhPHzuXygb+i6r6loR 2roibeg6Yz163yZSofMKFawKBQrHXbKIlS2H14m4OpQL3axGmK5vKWF/2d0LhI0eLw XRU6Pxr+tVBzC0WYtQVsTNFth81OuNWMdOCl0VgU8EbnZy5Yk7Mlx6qbICQxjabAz1 cukSQeSPOObOdiUGGxlx6ZAgUThKEJLHWD0OLspjeYoheEZhvMw+7yH0jtAvgMWv1x N+2nSUuz6qCEhcyF3MFcxkky2zKGBPAl2VE0snnH4u+Zs+tfrJ6xmbsN/g8Dbi1P0U g4IXYwF4W9Rpg== From: Joel Fernandes To: linux-kernel@vger.kernel.org, "Paul E . McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Jonathan Corbet , Shuah Khan , Randy Dunlap Cc: rcu@vger.kernel.org, Kunwu Chan , linux-arch@vger.kernel.org, lkmm@lists.linux.dev, linux-doc@vger.kernel.org Subject: [PATCH for-v7.5 02/14] Documentation/litmus-tests: Add SRCU fastpath scan-before-anchor test Date: Thu, 12 Nov 2026 19:57:29 -0500 Message-ID: <20261113005747.2977123-3-jfern@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20261113005747.2977123-1-jfern@kernel.org> References: <20261113005747.2977123-1-jfern@kernel.org> X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Kunwu Chan 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. 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 Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes --- Documentation/litmus-tests/README | 19 +++++++ .../SRCU-fastpath-scan-before-anchor.litmus | 52 +++++++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 Documentation/litmus-tests/srcu/SRCU-fastpath-scan-before-anchor.litmus diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index 6c666f3422ea..4d4ec9c6f2cc 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -78,3 +78,22 @@ RCU+sync+read.litmus RCU+sync+free.litmus Both the above litmus tests demonstrate the RCU grace period guarantee that an RCU read-side critical section can never span a grace period. + +SRCU (/srcu directory) +---------------------- + +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. diff --git a/Documentation/litmus-tests/srcu/SRCU-fastpath-scan-before-anchor.litmus b/Documentation/litmus-tests/srcu/SRCU-fastpath-scan-before-anchor.litmus new file mode 100644 index 000000000000..7df0641b5470 --- /dev/null +++ b/Documentation/litmus-tests/srcu/SRCU-fastpath-scan-before-anchor.litmus @@ -0,0 +1,52 @@ +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. 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); +} + +P2(int *seq, int *ctr) +{ + int r3; + int r4; + + r3 = READ_ONCE(*ctr); + smp_mb(); + r4 = READ_ONCE(*seq); +} + +filter (0:r2 = 0) +exists (2:r3 = 1 /\ 2:r4 = 0) -- 2.54.0