From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(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 6EE7F392C50
	for <linux-kernel@vger.kernel.org>; Thu, 12 Mar 2026 19:10:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1773342649; cv=none; b=bnQQWnbmyIAKc1UROqYzhjidmNbCx2g3/RTMYpyM516UqCRJOXvKWDBwBE+wFICk1rUGeJEM30G0m2f3RzmipkhmUPKxM1MJvmuX9nvBOnrJc6J/TnC2cnno0s99L4dJ5ruX4YDV3ytovq2VchWclX4dwYJyoJ31FCtbt11yv70=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1773342649; c=relaxed/simple;
	bh=AUIE9NKmp6lg4TQjyNfOACCd15BDjb6dq9HU31nP7vs=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=RO51WqkHz/GWlE2PYJEmW9IWsCSSa3YGD2mMO3XUU09CKQkqqXmorfUykGqwWC+JDfwL9okHlIcjy5sTR3LRURhyTvVWaFQ31d1OLU3z26ej9eJQ71Zq7YvXhAqJcJq57MRucDgkN3M4zOcrthrba5sVn59YFKupd+pgelXeQ0g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Es9xbYcj; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Es9xbYcj"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78D84C4CEF7;
	Thu, 12 Mar 2026 19:10:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1773342649;
	bh=AUIE9NKmp6lg4TQjyNfOACCd15BDjb6dq9HU31nP7vs=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
	b=Es9xbYcj5MLsg3aMA5mzigMUnzdnBX+X0ovg4ULUq2094PqLWppYkggd6bwxphXHS
	 jaDrTL/L+lNyaV6rHXlvshel6ke/hs0l2Bg7wrqswcXHnlFC2V9X5EaCjYZxGJrsdu
	 vYfqXiFSXvu2MBAuOQ1gcdArL3377qTAlpdQDE8Aw9OXkSz0Ed5G86LjAzsbHWL2G1
	 hLvCxcb7H5B61aiD6jrlvFO+pL2ZRl536mTE60aTCuXI/zTk9aYrb/s8qZjfPuRQUw
	 JKbxzTQE/VUeWK5W0fLKPXvtB//3JYgJj0BR+cfj9zHf2Qz8qZNsxDTiuRFbXTAlRx
	 Jn+Gzk7+aKBCw==
From: Thomas Gleixner <tglx@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, =?utf-8?Q?Andr?=
 =?utf-8?Q?=C3=A9?= Almeida
 <andrealmeid@igalia.com>
Cc: linux-kernel@vger.kernel.org, Carlos O'Donell <carlos@redhat.com>,
 Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Peter Zijlstra
 <peterz@infradead.org>, Florian Weimer <fweimer@redhat.com>, Rich Felker
 <dalias@aerifal.cx>, Torvald Riegel <triegel@redhat.com>, Darren Hart
 <dvhart@infradead.org>, Ingo Molnar <mingo@redhat.com>, Davidlohr Bueso
 <dave@stgolabs.net>, Arnd Bergmann <arnd@arndb.de>, "Liam R . Howlett"
 <Liam.Howlett@oracle.com>
Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock
In-Reply-To: <c2eec0c1-1509-4c32-92c0-2f256543a83e@efficios.com>
References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com>
 <2993f778-c4f4-4aa8-8e42-1dca4d5e29e1@igalia.com>
 <c2eec0c1-1509-4c32-92c0-2f256543a83e@efficios.com>
Date: Thu, 12 Mar 2026 20:10:45 +0100
Message-ID: <87pl58q2x6.ffs@tglx>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 12 2026 at 10:04, Mathieu Desnoyers wrote:
> On 2026-03-12 09:46, Andr=C3=A9 Almeida wrote:
>> The interface that I would propose here would be a bit more "generic" or=
=20
>> "flexible":
>>=20
>> __vdso_robust_futex_unlock(void *uaddr, int uval, struct=20
>> robust_list_head *head, unsigned int flags)
>
> I agree on adding explicit "uval" and pointer to robust list head,
> I'm not convinced that the rest is an improvement.
>
> This would require the caller to deal with errors, making it
> more complex than a simple replacement for atomic xchg/cmpxchg.
>
> "flags" could be unsupported, so the handler would have to deal with
> -EINVAL.

What's the problem with that? pthread_mutex_unlock() has a return value
too.