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 100C73E3C5E for ; Wed, 18 Mar 2026 14:48:10 +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=1773845297; cv=none; b=JLKbXcw5BTsJkcUxuzMgMe7O7Q+3NAs9WTPnDVzxBH1Kex6hisIxC1PC0VbNr8cLmdnaxwIshNopv2lfFnt7gRz3bV98ArfYvLa7qVTQHpvnI7QPDNcXCDKPYvC6ASIxgGV+wOuxlJKYpIlViP5MAWjHu0tPykDNqqtK5JySI5M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773845297; c=relaxed/simple; bh=VBL6WI/l4KOJtmDMPLA7pEO33+r+85KPjZW3tTXZk+4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IAXSMj6KXZzFHaUGH8CutAe1V45MOlYGJnE7Gafm5HBa8OqITUNqUBmAG3MpL/Om5X5f4rRVV27eIFcPAh80Y7mMg/RWomLoOA5Kpwgn6EQ5UmnK3h/6jrk9f9Jx+MHP9znJS8ykj10IbP+rFjfg/l0GfV8/AD+fTbodLfe9wLw= 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=phvK/bIq; 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="phvK/bIq" 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=9l94964is2VDzIehwfFexiEuVg36+Xh2W2cTMrlLsvg=; b=phvK/bIqdMXgg9XwLntwyuvV1X UlN2car65k0sl1lMxsZyw0rRW4We141C0qU/oe4ihVH3pnyaJgbjpk87sba08w3DrA99ZuPWp7Zc2 7T9uaZVTD1R0P5F8x2OFFP4Iy/cwdcBEQ0Rw2QjjOqdQco2qNDy+aRrsNtQ6gur5kiiIHnoq5hnWC 5X/qANvq9PJ/BE7KwNDIZ/tzIUYHVuYfzl6yqRLnt9AWn9xwjl6JJqTuQVKOo8Od0ayDGPyMGRdBl HyXHSYl6k3Q+h31pJaQ899VJPXHBg5FNmBjLPuzrTl0qmoyho+KaGFmoRMb/FakBwzDyJOeBWTk4F Xooc/GUQ==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2sBj-0000000BSgy-3rcc; Wed, 18 Mar 2026 14:48:00 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id D25403007C4; Wed, 18 Mar 2026 15:47:58 +0100 (CET) Date: Wed, 18 Mar 2026 15:47:58 +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: <20260318144758.GB3739106@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> <20260318080201.GE3738010@noisy.programming.kicks-ass.net> 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: <20260318080201.GE3738010@noisy.programming.kicks-ass.net> On Wed, Mar 18, 2026 at 09:02:01AM +0100, Peter Zijlstra wrote: > 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. Ah, it was for the sys_membarrier() thing. And yes, a syscall itself does not imply memory ordering for all architectures. And since this very much needs release semantics, it is best to be explicit about that.