linux-kernel - Re: [RFC] jiffies_till_first

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251226021559.GA949635@joelbox2>
Date: Thu, 25 Dec 2025 21:15:59 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu <rcu@...r.kernel.org>, Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, Davidlohr Bueso <dave@...olabs.net>,
	Josh Triplett <josh@...htriplett.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang@...ux.dev>
Subject: Re: [RFC] jiffies_till_first_fqs off by 1

On Thu, Dec 25, 2025 at 10:54:20AM -0800, Paul E. McKenney wrote:
> On Tue, Dec 23, 2025 at 09:06:19PM -0500, Joel Fernandes wrote:
> > Hi Paul,
> > 
> > On Tue, Dec 23, 2025 at 03:53:23PM -0800, Paul E. McKenney wrote:
> > > On Tue, Dec 23, 2025 at 12:38:19PM -0500, Joel Fernandes wrote:
> > > > During studying some synchronize_rcu() latencies, I found that the
> > > > jiffies_till_first_fqs value passed to the timer tick subsystem does is always
> > > > off by one. This is natural due to calc_index() rounding up.
> > > > 
> > > > For example, jiffies_till_first_fqs=3 means the "Jiffies till first FQS" delay
> > > > is actually 4ms. And same for the next FQS. In fact, in testing it shows it can
> > > > never ever be 3ms for HZ=1000. And in rare cases, it will go to 5ms probably due
> > > > to interrupts.
> > > > 
> > > > Considering this, I think it is better to reduce the jiffies_till_first_fqs by 1
> > > > before passing it to the wait APIs.
> > > > 
> > > > But before I wanted to send a patch, I wanted to get everyone's thoughts.
> > > > Considering this the RFC.
> > > 
> > > Inadvertent passing of the value zero?
> > 
> > This should not be an issue because at the moment, even a value of
> > jiffies_till_first_fqs == 0 waits for ~1 jiffie due to schedule_timeout(0).
> > 
> > But you raise a good point, we should cap the minimum allowed jiffie value
> > for the fqs parameters to 1 so that we don't pass schedule_timeout() with
> > negative values when/if we do the reduce-by-one approach.
> 
> There is a potential use case for jiffies_till_first_fqs=0 and no wait,
> which would be systems that want to scan for idle CPUs immediately after
> the grace period has been initialized.  Note the word "potential".  ;-)

Sure, we could add support for that but that would be new behavior that is
not in the existing code.

So jiffies_till_first_fqs=0 today, I think it is not 'working as intended'
because it will never not wait I think.

So we should fix that too? Or maybe it can be a patch separate from this
(that I can work on). I think no harming in allowing that mode, at least it
will be more in line with the expected outcome.

> 
> If we want to support this, then perhaps we would need to avoid that
> schedule_timeout(0).  Or rcu_gp_fqs_check_wake(), as the case may be.

True.

thanks,

 - Joel