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 A5C41189F43 for ; Tue, 17 Mar 2026 20:47:12 +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=1773780436; cv=none; b=Z8Ska9XNCkQku7RSs+IcYqwPV/GgHfmnMmkESpUaEjxNrwLaaXxFOCHomwLr7HbU1R8irveOGp4je9PtGXs/BaWAwhXmeiI4X55AN8bM4f1vCGcii4FkT7vIcWMp7gedypYfgfGZb5WICNp9EXHoF8skyKz8bPK4HCH2taBokaU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773780436; c=relaxed/simple; bh=obBiSOvFvIsggdCQFOA6/EiB/krl/HoWYhMIV3SyNbw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OHxZuZjwvs0hinMXWF+dCylWs0MqTLoppTEJOY2Xuq9dbGPmXuC2Oesa6SgkZqseBM25kX8ISKBh3N5spOTKLIqWusAb45XshzXR7/yFaRJuay5NN2H0sBzQ9HSd2b5wjap73GAXlu+3MUCFr4tuPOwxSK/0b5DorzxJD7Ksl4A= 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=lKb8n7jK; 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="lKb8n7jK" 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=xDbzTYhpRszOj3WquLD9ej2AA2QkThV48xba8BFigN8=; b=lKb8n7jKFyJZnLosPkbpnx+oPO d+8GMlnXjhtk2Qc/RDO+XXb55PcAeBvrBKysV3nXiiYhZOkghaIRZRUTBRO0iYFqkLUS6Yi6oPK7p zxL3O+GRKbIgqY2HSlXdmbDN3q5NB5xYvK78i8OlBQ0pfqTzhZCaJMgBaC0+o+PdIuPOHgEURqjEF eEUFqk9NOiBN/VYsf6qPAFOXeXgjtjgJ59JG/cAkAgUEgoxGUu+73dScQ2axuEAWB5S0ThuU5+pVb cTEJGEoMVoQX7F4aBlySDV/Ume0Dmuw1hvGh4GVOzJhWIK/6dyXvy2xQ4ZHgzxaWyd+a+4gAKp0AO xwkmeDNA==; 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 1w2bJV-00000009uuV-0Z4R; Tue, 17 Mar 2026 20:46:54 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 8E484301BD5; Tue, 17 Mar 2026 21:46:51 +0100 (CET) Date: Tue, 17 Mar 2026 21:46:51 +0100 From: Peter Zijlstra To: =?iso-8859-1?Q?Andr=E9?= Almeida Cc: Thomas Gleixner , 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: <20260317204651.GJ2872@noisy.programming.kicks-ass.net> References: <20260316162316.356674433@kernel.org> <20260316164951.209959583@kernel.org> <218577a9-1381-4470-a638-fa87d014da61@igalia.com> 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: <218577a9-1381-4470-a638-fa87d014da61@igalia.com> 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.