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 411CB3081A2 for ; Tue, 17 Mar 2026 22:40:16 +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=1773787216; cv=none; b=Fl57U+2/1kd7YS0CG0BcNebzAIk4kX6b979Sp9YscADBmOH0VikIl6tgofrhzKh3n4XQand5l8NZ6lN86Bbe6XBMiMubPLPvxggkK8T2X/tR+JJA4Lwa1EjMIxAid30b1fj/VQunJmWOWCnxDQRwtCV/qKlfIx8QpjEEwQABy2U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773787216; c=relaxed/simple; bh=VcKEFsKjyoTHx3HiIZrRWTVeXKYLhDYl7KEWECUY1A4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=o5btuhX4VR1i8UMEz4k7FSinaf0SgpkM4OwCwocAf/ZfPKgSDEzANXXX5FNwLt3Tt+jq/OUANp9WuHgfq6c5APucZIZJO3s7PjNAorgCLWmW/fktJXP0i5S9wyKqnOJTPijCauNxJzQGpVA3IymOoqoLBCCmawPdVWA1P9p50Vs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bLDj8Y+H; 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="bLDj8Y+H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DFB2C4CEF7; Tue, 17 Mar 2026 22:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773787216; bh=VcKEFsKjyoTHx3HiIZrRWTVeXKYLhDYl7KEWECUY1A4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bLDj8Y+HV9OKx9ZjIvuDqt+PMRXKMnZc5xdLdnN5kIz6KtoYD4AW9X1T83mMWvq6V 8vDA+EZRBx8dHwETGA6tosyv7RQpRP1+Pw2rQGexG7jwglPQpc+32WMf9j1zLwmJLG pu+yy+LKu8mnGktHUjRekJWDsByQdF4vCH6wX2vzqa8REfF0sh55Cosc2/glxl26Ac 5UcdSfZ0giVbQr9GvBDSQvHlVgnUfBy3BjOQWO0oQJnbISirtlFEVbZWbiZl2q9YE9 Iv73NkzythBiH7R2U4GETYvSOqMmmB9/l5+zxC00z9VfCjQ+b9Fx2Zasc2y3Rf9uVe hP3kpdJuVY9Iw== From: Thomas Gleixner To: Peter Zijlstra , =?utf-8?Q?Andr=C3=A9?= Almeida Cc: LKML , Mathieu Desnoyers , Sebastian Andrzej Siewior , Carlos O'Donell , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [patch 4/8] futex: Add support for unlocking robust futexes In-Reply-To: <20260317204651.GJ2872@noisy.programming.kicks-ass.net> References: <20260316162316.356674433@kernel.org> <20260316164951.209959583@kernel.org> <218577a9-1381-4470-a638-fa87d014da61@igalia.com> <20260317204651.GJ2872@noisy.programming.kicks-ass.net> Date: Tue, 17 Mar 2026 23:40:12 +0100 Message-ID: <87wlzam65v.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 Tue, Mar 17 2026 at 21:46, Peter Zijlstra wrote: > On Tue, Mar 17, 2026 at 01:17:28PM -0300, Andr=C3=A9 Almeida wrote: >> Em 16/03/2026 14:13, Thomas Gleixner escreveu: >>=20 >> [...] >>=20 >> > --- a/kernel/futex/waitwake.c >> > +++ b/kernel/futex/waitwake.c >> > @@ -150,12 +150,32 @@ void futex_wake_mark(struct wake_q_head >> > } >> > /* >> > + * If requested, clear the robust list pending op and unlock the futex >> > + */ >> > +static bool futex_robust_unlock(u32 __user *uaddr, unsigned int flags= , void __user *pop) >> > +{ >> > + if (!(flags & FLAGS_UNLOCK_ROBUST)) >> > + return true; >> > + >> > + /* First unlock the futex. */ >> > + if (put_user(0U, uaddr)) >> > + return false; >> > + >>=20 >> On glibc code, the futex unlock happens atomically: >>=20 >> atomic_exchange_release (&mutex->__data.__lock, 0) >>=20 >> Is OK to do it unatomically? >>=20 >> I couldn't find a race condition given that the only thread that should = be >> able to write to the futex address must be the lock owner anyways, but I >> don't know why userspace does it atomically in the first place. > > So userspace could probably get away with doing: > > atomic_store_explicit(&mutex->__data.__lock, 0, memory_order_release); > > IOW a plain store-release. And yeah, I think the kernel probably should > do a store-release too. It doesn't matter on x86, but if we have a > weakly ordered architecture where the mode transition is also not > serializing, we could be having trouble. No. There is a syscall in between and if that is not sufficient then the architecure has more severe troubles than that store, no? Thanks, tglx