From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 EDD0A35C1B7 for ; Wed, 18 Mar 2026 08:02:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773820943; cv=none; b=ms4ffKYBbHwjuA/TWOof4M0Z/kWwTf/YwuoXQTgjIIWptaCyX0X8Cz3+AkTArrLFF+xZ8A4A6/Txz6BRVxlzMkOqJr4T2OlXUVsYW6yhgDY0xzA/5TYGeBJeV2nuG5qdgoNf93geQVgWZJGY0E/YZEhYGSC0DVNwEtxFZGpiypk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773820943; c=relaxed/simple; bh=50D19XPyXkNC5WG5gsmxBFjPEucJKMJiKKvlMheuWvY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T57Fz1klB6sVIMou0RN4Z7xL64C9uQ0u2jkPJnEaXjXeEKV1jmJSafC/kzd4X/R5eW8SeR19tCFVc9eGB6rI7ospOpwqdW2tlu9U5DCNUWApvdQRceNbdKNiWHSCzagDUFPCXA71PIehos18qscB6S6qeCn5SZMGBp75z/QJ7aU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=dyblOkt4; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dyblOkt4" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=wPs4Y+BvTWOQhi7GQlpB5CX+MGUdILwPtwTvxEJH+LI=; b=dyblOkt4B3awo9l6mos150Anm/ r5RR4/s1/Rcq6Q38tglYeIRByAJDM0Gpi24uteASavUuiXNyAJ8+EM1xOFlLSnHkCSF4S3iietctd bkfQCGpbyVDfe1XfHyzu0E5ybAsL8CZrHIqeX28ga/fVFRhhZnEKKol29Y6XcnysPPNDBIwgq4Hm8 TB/YaEa+ZHuwzDsU6LqE3qgkxX4i//E7V2EpT3DHO8Hpoqso2hX4s8myFv/oqYqf2hLiW9V4pioKO 5Vss4v7fj5lFObBEjyKfuiWek1Wn32vupZDHpCaGN1rH0LmNqoK1LrJUWr9RGDsYpCcVWZ2zVJn7C rmeahNlw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2lqy-0000000AcbR-1n6F; Wed, 18 Mar 2026 08:02:08 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B323E3032B7; Wed, 18 Mar 2026 09:02:01 +0100 (CET) Date: Wed, 18 Mar 2026 09:02:01 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: =?iso-8859-1?Q?Andr=E9?= Almeida , 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 Message-ID: <20260318080201.GE3738010@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> <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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87wlzam65v.ffs@tglx> On Tue, Mar 17, 2026 at 11:40:12PM +0100, Thomas Gleixner wrote: > On Tue, Mar 17 2026 at 21:46, Peter Zijlstra wrote: > > On Tue, Mar 17, 2026 at 01:17:28PM -0300, André Almeida wrote: > >> Em 16/03/2026 14:13, Thomas Gleixner escreveu: > >> > >> [...] > >> > >> > --- 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; > >> > + > >> > >> On glibc code, the futex unlock happens atomically: > >> > >> atomic_exchange_release (&mutex->__data.__lock, 0) > >> > >> Is OK to do it unatomically? > >> > >> 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? So I think we once tried to determine if syscall could be considered to imply memory ordering, and I think the take-away at the time was that we could not assume so. But its been a long time, maybe I misremember.