[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250310162710.K9WY5tzN@linutronix.de>
Date: Mon, 10 Mar 2025 17:27:10 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
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 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.
> > Depending on those I could fold the fixes directly into the patches and
> > repost the whole thing or prepare you patches that can be folded back
> > and send those.
>
> Please, it appears I don't have as much time as I would like :/
Sebastian
Powered by blists - more mailing lists