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: <ed89d87a-027e-4a99-8437-28258fd0f691@paulmck-laptop>
Date: Sat, 13 Jul 2024 12:32:10 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Rik van Riel <riel@...riel.com>
Cc: neeraj.upadhyay@...nel.org, linux-kernel@...r.kernel.org,
	rcu@...r.kernel.org, kernel-team@...a.com, rostedt@...dmis.org,
	mingo@...nel.org, peterz@...radead.org, leobras@...hat.com,
	imran.f.khan@...cle.com
Subject: Re: [PATCH  2/3] locking/csd_lock: Provide an indication of ongoing
 CSD-lock stall

On Sat, Jul 13, 2024 at 01:16:47PM -0400, Rik van Riel wrote:
> On Sat, 2024-07-13 at 22:28 +0530, neeraj.upadhyay@...nel.org wrote:
> > 
> > @@ -228,6 +241,7 @@ static bool
> > csd_lock_wait_toolong(call_single_data_t *csd, u64 ts0, u64 *ts1, in
> >  		cpu = csd_lock_wait_getcpu(csd);
> >  		pr_alert("csd: CSD lock (#%d) got unstuck on
> > CPU#%02d, CPU#%02d released the lock.\n",
> >  			 *bug_id, raw_smp_processor_id(), cpu);
> > +		atomic_dec(&n_csd_lock_stuck);
> >  		return true;
> >  	}
> >  
> 
> So we decrement it when it gets unstuck. Good.
> 
> > @@ -251,6 +265,8 @@ static bool
> > csd_lock_wait_toolong(call_single_data_t *csd, u64 ts0, u64 *ts1, in
> >  	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 (firsttime)
> > +		atomic_dec(&n_csd_lock_stuck);
> > 
> 
> However, I don't see any place where it is incremented when things
> get stuck, and this line decrements it when a CPU gets stuck for
> the first time?
> 
> Should this be an atomic_inc?

Good catch, thank you!  I will go get that brown paper bag...

							Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ