From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41F2338F63C for ; Fri, 13 Mar 2026 12:13:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773403984; cv=none; b=q/U25f6aIejoUaDytzhi/ZO5zcmr8BXFAyhDE0qldTuj9PRdyoNOSLQU1Q+y1ilVCJFOb3u/F3P/5aH9o1rn0zBFR5k6KniSFCp11QrpXpeZ7145JB6jFHL32zS4jy+HmFgbj1TGkXzW76mLAuwbku/X2IBHuEgNXD0eICuqFyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773403984; c=relaxed/simple; bh=bf63Y2IsZFM/5VH1OgKszSB44bAt4R6A8JzD0Vzas+Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oMmDzk3lB+ELa6NSUHXWclYiG3S5s3EVb9EX3RzHi0PfqYGZrL4S4XDSugHK//3oW8GKfHJ1wBZlxAxFtGQaU5vf8uUxWCUG6S6Q4xNhsNnkVuzk5LoKGMrwF9ExlXAH5iPMi4J4DX3rIh1Jt1H+M/mVDW1SB9/QaULQD5Op50g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=cHVZwthN; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=ToHmaJsL; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="cHVZwthN"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ToHmaJsL" Date: Fri, 13 Mar 2026 13:12:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773403981; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XfLzgBABN6aQx/ceCLi+vfkZnCBK/xbYrbVIzk4kLac=; b=cHVZwthNFaSRp5A27Cn5GX5UU37dxNzfroOsKEf4Vhh6rQtoqTY9FzPn4+62YI/w4zYq9L IecgDyMiWGuGa21Zu6Dz+LIvk8myAZt3LxtWVwYYaUdE5D0VkVn63KSiZmdUgOtNglddOj A9NhWIo6jp+naTNFSbhbaVRYz78OXTfo4KgfzY67sZlLeciyN/V2mcbjfmF1m1yM3obtgF mNOfk7nkjC4bX67P4N3l1DukhnqT40Vx45nBJJIMXb/aktRNAukNiO+C/77JKuCCDAAzea QXx1ZLSlxPLmORqpGTpEZ6G7Prg8k5j1QdSe6go5Xj4M6cVi65Y9iX2NMD0AiA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773403981; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XfLzgBABN6aQx/ceCLi+vfkZnCBK/xbYrbVIzk4kLac=; b=ToHmaJsLNpV8nbZA3zjrMTanl4z4X/iwDyhxgMEZxOBItOa+Db+u3xJ1/tOm8SHMsRrUpy VIb4+XCkWEOzDSAg== From: Sebastian Andrzej Siewior To: Mathieu Desnoyers Cc: Thomas Gleixner , =?utf-8?B?QW5kcsOp?= Almeida , linux-kernel@vger.kernel.org, Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock Message-ID: <20260313121259.XYZi8U-j@linutronix.de> References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <87eclopu0j.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: On 2026-03-12 18:52:43 [-0400], Mathieu Desnoyers wrote: > On 2026-03-12 18:23, Thomas Gleixner wrote: > > On Wed, Mar 11 2026 at 14:54, Mathieu Desnoyers wrote: > [...] > >=20 > > TBH, all of this is completely overengineered and tasteless bloat. > >=20 > > The exactly same thing can be achieved by doing the obvious: > >=20 > > struct robust_list_head2 { > > struct robust_list_head rhead; > > u32 unlock_val; > > }; > >=20 > > // User space > > unlock(futex) > > { > > struct robust_list_head2 *h =3D ....; > >=20 > > h->unlock_val =3D 0; > > h->rhead.list_op_pending =3D .... | FUTEX_ROBUST_UNLOCK; > >=20 > > xchg(futex->uval, h->unlock_val); >=20 > Here is the problem with your proposed approach: >=20 > "XCHG =E2=80=94 Exchange Register/Memory With Register" > ^^^^^^^^ >=20 > So only one of the xchg arguments can be a memory location. > Therefore, you will end up needing an extra store after xchg > to store the content of the result register into h->unlock_val. But can't we also assign a role to pthread_mutex_destroy() here? So it would ensure that the futex death cleanup did run for every task having access to this memory? So it is either 0 or pid-of-dead-task before this memory location can be used again? > Thanks, >=20 > Mathieu Sebastian