linux-kernel - RE: [PATCH v2 1/1] futex: 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]

Message-ID: <16a6a6f28cc547b7a0a27ae6eebcca43@AcuMS.aculab.com>
Date: Fri, 24 May 2024 07:52:05 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'André Almeida' <andrealmeid@...lia.com>, "Mathieu
 Desnoyers" <mathieu.desnoyers@...icios.com>, Peter Zijlstra
	<peterz@...radead.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Thomas
 Gleixner" <tglx@...utronix.de>, "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"
	<linux-api@...r.kernel.org>, Christian Brauner <brauner@...nel.org>, "Florian
 Weimer" <fw@...eb.enyo.de>, "carlos@...hat.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" <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" <longman@...hat.com>, "kernel-dev@...lia.com"
	<kernel-dev@...lia.com>
Subject: RE: [PATCH v2 1/1] futex: Add FUTEX_SPIN operation

From: André Almeida
> Sent: 23 May 2024 21:07
> 
> Add a new mode for futex wait, the futex spin.
> 
> Given the FUTEX2_SPIN flag, parse the futex value as the TID of the lock
> owner. Then, before going to the normal wait path, spins while the lock
> owner is running in a different CPU, to avoid the whole context switch
> operation and to quickly return to userspace. If the lock owner is not
> running, just sleep as the normal futex wait path.
> 
> The user value is masked with FUTEX_TID_MASK, to allow some bits for
> future use.
> 
> The check for the owner to be running or not is important to avoid
> spinning for something that won't be released quickly. Userspace is
> responsible on providing the proper TID, the kernel does a basic check.

The kernel needs to do something to stop a user-process spinning in-kernel
indefinitely.

...
> +static inline bool task_on_cpu(struct task_struct *p)
> +{
> +#ifdef CONFIG_SMP
> +	return !!(p->on_cpu);
> +#else
> +	return false;
> +#endif
> +}

I suspect that isn't going to work in a VM where the entire 'cpu'
can be sleeping.

This is similar to the (I don't think works properly) check
in the 'osq' (optimistic spin queue) used when waiting for
the thread spinning on a mutex/rwlock to change state.

IIRC that code also checks whether the current thread should
be pre-empted by a higher priority process.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)