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 30A521A0712 for ; Thu, 12 Mar 2026 20:20:00 +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=1773346800; cv=none; b=GKoJ1ONEzQRd5THYHIT03Rmoz+NT7KsyRNcHBkL+4EodDkNAl4FIO6RahWFoBOOjrjM1qe8yvijWh5o3Cr7AHvcpsBqyuT6QBrMAkgW/1b4dQ5plKBiKotvJ3P5ZWS0XEBix3+EQWTCVOvTvelyqEYpaiG/40QnZpocljC9CFQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773346800; c=relaxed/simple; bh=JYtToVEmqlawJDynE3iXW07r54lKdwJlbrDubTJAp3Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Gm7dMF9SXDx5lWAuy+Cxtj73lIKPWCb6Sj42ScpDKV3nFBljxQUhuVSIXr/+O3MAFLhLeCNOEEVFPzhNkDhxJUd04h/qMU9xP8e26ugFxR8VF2muJtyWd88HAV53fQuwCJ5/enIkbpaFAw4SR2X/9ziFZJr+knoNrkb62JPrj/M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=idDe/y6n; 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="idDe/y6n" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F806C2BC87; Thu, 12 Mar 2026 20:19:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773346800; bh=JYtToVEmqlawJDynE3iXW07r54lKdwJlbrDubTJAp3Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=idDe/y6n9g9oEXMyv4WIIjUEDA23vUSqy2at23GwDarmyxMTESCaz0SQAGf6b1/uS DPWV+pFDk8e0GicXLGsJZ1UbU2eTX51gi6Mf0+10pj53LzK8M6RBZmVnetupD+J9Wz ++yNu9B/SidgvQrphMMCBYhoqVw8/hYidNOB6XP9WsnyoAuApk5uYRkoVqYT6DhHGT jc51p8ntRAFshoS4UNEdJH4uhSLZXLNxLXHuKTFeqlZovTPseA2NHlw4pkIdpvj+Nw zHP4+J+qz/qO8VvY72PaU9QuvBLzCAcU3qCKazaqNNCcg1c4+z8JOtjgUeeuev13QK baiN0oOvpjUCA== From: Thomas Gleixner To: =?utf-8?Q?Andr=C3=A9?= Almeida , Mathieu Desnoyers Cc: linux-kernel@vger.kernel.org, Carlos O'Donell , Sebastian Andrzej Siewior , 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 In-Reply-To: <2993f778-c4f4-4aa8-8e42-1dca4d5e29e1@igalia.com> References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <2993f778-c4f4-4aa8-8e42-1dca4d5e29e1@igalia.com> Date: Thu, 12 Mar 2026 21:19:56 +0100 Message-ID: <87ikb0pzpv.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-Transfer-Encoding: quoted-printable On Thu, Mar 12 2026 at 10:46, Andr=C3=A9 Almeida wrote: > Em 11/03/2026 15:54, Mathieu Desnoyers escreveu: > I would also have `uval` instead of `val =3D 0`, because even though the= =20 > most common semanthics for futex is that (LOCK_FREE =3D=3D 0), futex has = no=20 > predetermined semanthics of what each value means, and the userspace is=20 > free to choose what value they want to choose for a free lock. That's true for non-robust futexes, but robust futexes have clearly defined semantics vs. the userspace value: 0: unlocked !=3D 0: PID of the owner So uval is useless as the unlock value can't be anything else than 0, no? Thanks, tglx