linux-kernel - Re: [PATCH] rcu: Merge rcu_seq_done_exact() logic into rcu_seq

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: <999751de-b891-424d-a7b5-80bfa98793ff@paulmck-laptop>
Date: Tue, 4 Feb 2025 12:22:53 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: linux-kernel@...r.kernel.org, Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Josh Triplett <josh@...htriplett.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang1211@...il.com>, rcu@...r.kernel.org
Subject: Re: [PATCH] rcu: Merge rcu_seq_done_exact() logic into rcu_seq_done()

On Tue, Feb 04, 2025 at 10:44:45AM -0500, Joel Fernandes wrote:
> On Thu, Jan 30, 2025 at 12:56 AM Paul E. McKenney <paulmck@...nel.org> wrote:
> > By "where we were initially", one might reasonably guess that you meant
> > that the initial value and the target are one and the same.  But I suspect
> > that you are thinking of a third value, the value of the underlying
> > grace-period sequence number at the time of the call to rcu_seq_snap().
> > But you might be thinking of something else entirely.
> >
> > > Now we move rcu_seq_done_exact. It has the exact same behavior except
> > > that instead of ULONG_MAX/2, the above situations are shrunk to about
> > > 10 counts from the target. So if target is 28, then the initial
> > > sequence should have been at least 18 to avoid false-positive, but
> > > again it is possible and I certain see in the code that it cannot be
> > > used this way.. (at least so far).. So all we are left with is the
> > > false-negative band of ~2.5 GPs..
> >
> > Here, I have the same questions.  As you no doubt guessed.
> >
> > > About "what are the consequences of failing to get this right".  I
> > > believe false-positive is unacceptable unless it is maybe debug code -
> > > that can break functionality in code, too short GPs and all that.
> > > However false-negative is OK as long as the usecase can retry later
> > > and can afford to wait. Did I get that much correct?
> >
> > Maybe?
> >
> > Please look at this on a per-use-case basis.
> 
> Sure. FWIW, I started a world-editable document here. I am planning to
> work on this a bit more before our meeting this week. If others
> knowledgeable like Frederic and others could make edits/comments,
> that'd be welcomed. But I basically summarized this whole thread here:
> https://docs.google.com/document/d/1sFNuGH4U6DFCE8sunbdWMjFhJhb1aG4goOJAnS6c6gQ/edit?usp=sharing
> 
> My thought is (AFAICS), this patch is still valid and
> rcu_seq_done_exact is a potentially better replacement to
> rcu_seq_done. But famous last words...

Let's start with the use case where the sequence number is being used
by rcu_barrier().  What happens?

							Thanx, Paul