linux-kernel - Re: [PATCH v9 00/11] futex: Add support task local hash maps.

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: <20250311101714.GC19424@noisy.programming.kicks-ass.net>
Date: Tue, 11 Mar 2025 11:17:14 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
	André Almeida <andrealmeid@...lia.com>,
	Darren Hart <dvhart@...radead.org>,
	Davidlohr Bueso <dave@...olabs.net>, Ingo Molnar <mingo@...hat.com>,
	Juri Lelli <juri.lelli@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Valentin Schneider <vschneid@...hat.com>,
	Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v9 00/11] futex: Add support task local hash maps.

On Mon, Mar 10, 2025 at 05:27:10PM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-03-10 17:01:02 [+0100], Peter Zijlstra wrote:
> > On Wed, Mar 05, 2025 at 10:02:37AM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2025-03-04 15:58:39 [+0100], To Peter Zijlstra wrote:
> > > > hash. That is why I had the `released' member.
> > > 
> > > The box was still alive this morning so it did survive >12h testing. I
> > > would bring back the `released' member back unless you have other
> > > preferences.
> > 
> > Like I just wrote in that other email; I'm a bit confused as to how this
> > can happen. If rcuref_put() returns success, then the value is DEAD. It must
> > then either be decremented below RELEASED or incremented past NOREF in
> > order for rcuref_read() to no longer return 0.
> 
> We can't rely on 0 to be released as it might become active. We could
> change rcuref_read() to return 0 if it could be obtained and -1 if it
> can not.
> We don't have many users atm so an audit should be quick.

Right, so I failed to understand initially. When DEAD it stays 0, but
there is indeed the one case where it isn't yet DEAD but still returns
0.

Making the DEAD return -1 seems like a good solution.