linux-kernel - Re: [PATCH v12 00/21] futex: Add support task local hash maps, FUTEX2_NUMA and FUTEX2

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: <20250506073611.GH4198@noisy.programming.kicks-ass.net>
Date: Tue, 6 May 2025 09:36:11 +0200
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 v12 00/21] futex: Add support task local hash maps,
 FUTEX2_NUMA and FUTEX2_MPOL

On Mon, May 05, 2025 at 09:30:36AM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-05-03 12:09:05 [+0200], Peter Zijlstra wrote:
> > On Fri, May 02, 2025 at 09:48:07PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 16, 2025 at 06:31:42PM +0200, Sebastian Andrzej Siewior wrote:
> > > > On 2025-04-16 18:29:00 [+0200], To linux-kernel@...r.kernel.org wrote:
> > > > > v11…v12: https://lore.kernel.org/all/20250407155742.968816-1-bigeasy@linutronix.de
> > > 
> > > I made a few changes (mostly the stuff I mailed about) and pushed out to
> > > queue/locking/futex.
> > 
> > And again, with hopefully less build errors included :-)
> 
> Okay. I guess the NUMA part where the nodeid is written back to userland
> if 0 was supplied is not an issue. I was worried that if you fire
> multiple threads which end up in the sys_futex_wait() at the same time,
> waiting on the same addr on two nodes and the "current" nodeid is used
> then the variable might be written back twice with two node ids. The
> mpol interface should report always the same one.

Well, if you do stupid things, you get to keep the pieces or something
along those lines. Same as when userspace goes scribble the node value
while another thread is waiting and all that.

Even with the unconditional write back you're going to have a problem
with concurrent wait on the same futex.