linux-kernel - [PATCH rcu 02/15] rcutorture: Start rcu_torture_writer() after rcu_torture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250709104215.15562-3-neeraj.upadhyay@kernel.org>
Date: Wed,  9 Jul 2025 16:12:02 +0530
From: neeraj.upadhyay@...nel.org
To: rcu@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
	paulmck@...nel.org,
	joelagnelf@...dia.com,
	frederic@...nel.org,
	boqun.feng@...il.com,
	urezki@...il.com,
	rostedt@...dmis.org,
	mathieu.desnoyers@...icios.com,
	jiangshanlai@...il.com,
	qiang.zhang1211@...il.com,
	neeraj.iitr10@...il.com,
	neeraj.upadhyay@....com,
	"Neeraj Upadhyay (AMD)" <neeraj.upadhyay@...nel.org>
Subject: [PATCH rcu 02/15] rcutorture: Start rcu_torture_writer() after rcu_torture_reader()

From: "Paul E. McKenney" <paulmck@...nel.org>

Testing of rcutorture's SRCU-P scenario on a large arm64 system resulted
in rcu_torture_writer() forward-progress failures, but these same tests
passed on x86.  After some off-list discussion of possible memory-ordering
causes for these failures, Boqun showed that these were in fact due to
reordering, but by the scheduler, not by the memory system.  On x86,
rcu_torture_writer() would have run quickly enough that by the time
the rcu_torture_updown() kthread started, the rcu_torture_current
variable would already be initialized, thus avoiding a bug in which
a NULL value would cause rcu_torture_updown() to do an extra call to
srcu_up_read_fast().

This commit therefore moves creation of the rcu_torture_writer() kthread
after that of the rcu_torture_reader() kthreads.  This results in
deterministic failures on x86.

What about the double-srcu_up_read_fast() bug?  Boqun has the fix.
But let's also fix the test while we are at it!

Reported-by: Joel Fernandes <joelagnelf@...dia.com>
Reported-by: Boqun Feng <boqun.feng@...il.com>
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@...nel.org>
---
 kernel/rcu/rcutorture.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index d1e0d61d8815..a209d2419cfd 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -4246,11 +4246,6 @@ rcu_torture_init(void)
 	/* Start up the kthreads. */

 	rcu_torture_write_types();
-	firsterr = torture_create_kthread(rcu_torture_writer, NULL,
-					  writer_task);
-	if (torture_init_error(firsterr))
-		goto unwind;
-
 	if (nrealfakewriters > 0) {
 		fakewriter_tasks = kcalloc(nrealfakewriters,
 					   sizeof(fakewriter_tasks[0]),
@@ -4283,6 +4278,12 @@ rcu_torture_init(void)
 		if (torture_init_error(firsterr))
 			goto unwind;
 	}
+
+	firsterr = torture_create_kthread(rcu_torture_writer, NULL,
+					  writer_task);
+	if (torture_init_error(firsterr))
+		goto unwind;
+
 	nrealnocbers = nocbs_nthreads;
 	if (WARN_ON(nrealnocbers < 0))
 		nrealnocbers = 1;
-- 
2.40.1