linux-kernel - [PATCH rcu 1/4] locking/csd_lock: Print large numbers as negatives

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: <20240816043917.26537-1-neeraj.upadhyay@kernel.org>
Date: Fri, 16 Aug 2024 10:09:14 +0530
From: neeraj.upadhyay@...nel.org
To: rcu@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
	kernel-team@...a.com,
	rostedt@...dmis.org,
	paulmck@...nel.org,
	neeraj.upadhyay@...nel.org,
	neeraj.upadhyay@....com,
	boqun.feng@...il.com,
	joel@...lfernandes.org,
	urezki@...il.com,
	frederic@...nel.org,
	mingo@...nel.org,
	peterz@...radead.org,
	leobras@...hat.com,
	imran.f.khan@...cle.com,
	riel@...riel.com,
	tglx@...utronix.de
Subject: [PATCH rcu 1/4] locking/csd_lock: Print large numbers as negatives

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

The CSD-lock-hold diagnostics from CONFIG_CSD_LOCK_WAIT_DEBUG are
printed in nanoseconds as unsigned long longs, which is a bit obtuse for
human readers when timing bugs result in negative CSD-lock hold times.
Yes, there are some people to whom it is immediately obvious that
18446744073709551615 is really -1, but for the rest of us...

Therefore, print these numbers as signed long longs, making the negative
hold times immediately apparent.

Reported-by: Rik van Riel <riel@...riel.com>
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Cc: Imran Khan <imran.f.khan@...cle.com>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: Leonardo Bras <leobras@...hat.com>
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>
Cc: Rik van Riel <riel@...riel.com>
Reviewed-by: Rik van Riel <riel@...riel.com>
Signed-off-by: Neeraj Upadhyay <neeraj.upadhyay@...nel.org>
---
 kernel/smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/smp.c b/kernel/smp.c
index aaffecdad319..e87953729230 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -249,8 +249,8 @@ static bool csd_lock_wait_toolong(call_single_data_t *csd, u64 ts0, u64 *ts1, in
 	cpu_cur_csd = smp_load_acquire(&per_cpu(cur_csd, cpux)); /* Before func and info. */
 	/* How long since this CSD lock was stuck. */
 	ts_delta = ts2 - ts0;
-	pr_alert("csd: %s non-responsive CSD lock (#%d) on CPU#%d, waiting %llu ns for CPU#%02d %pS(%ps).\n",
-		 firsttime ? "Detected" : "Continued", *bug_id, raw_smp_processor_id(), ts_delta,
+	pr_alert("csd: %s non-responsive CSD lock (#%d) on CPU#%d, waiting %lld ns for CPU#%02d %pS(%ps).\n",
+		 firsttime ? "Detected" : "Continued", *bug_id, raw_smp_processor_id(), (s64)ts_delta,
 		 cpu, csd->func, csd->info);
 	/*
 	 * If the CSD lock is still stuck after 5 minutes, it is unlikely
-- 
2.40.1