linux-kernel - Re: [RFC PATCH 0/1] Add FUTEX

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]

Date: Fri, 26 Apr 2024 12:14:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: André Almeida <andrealmeid@...lia.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	"Paul E . McKenney" <paulmck@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>,
	"H . Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
	linux-api@...r.kernel.org, Christian Brauner <brauner@...nel.org>,
	David.Laight@...lab.com, carlos@...hat.com,
	Peter Oskolkov <posk@...k.io>,
	Alexander Mikhalitsyn <alexander@...alicyn.com>,
	Chris Kennelly <ckennelly@...gle.com>,
	Ingo Molnar <mingo@...hat.com>, Darren Hart <dvhart@...radead.org>,
	Davidlohr Bueso <dave@...olabs.net>, libc-alpha@...rceware.org,
	Steven Rostedt <rostedt@...dmis.org>,
	Jonathan Corbet <corbet@....net>,
	Noah Goldstein <goldstein.w.n@...il.com>,
	Daniel Colascione <dancol@...gle.com>, longman@...hat.com,
	kernel-dev@...lia.com
Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation

On Fri, Apr 26, 2024 at 11:43:51AM +0200, Florian Weimer wrote:
> * André Almeida:
> 
> > With FUTEX2_SPIN flag set during a futex_wait(), the futex value is
> > expected to be the PID of the lock owner. Then, the kernel gets the
> > task_struct of the corresponding PID, and checks if it's running. It
> > spins until the futex is awaken, the task is scheduled out or if a
> > timeout happens.  If the lock owner is scheduled out at any time, then
> > the syscall follows the normal path of sleeping as usual.
> 
> PID or TID?

TID, just like PI_LOCK I would presume.

> I think we'd like to have at least one, possibly more, bits for free
> use, so the kernel ID comparison should at least mask off the MSB,
> possibly more.

Yeah, it should be using FUTEX_TID_MASK -- just like PI_LOCK :-)

I suppose the question is if this thing should then also imply
FUTEX_WAITERS or not.