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 B29873E6DE2
	for <linux-kernel@vger.kernel.org>; Wed, 18 Mar 2026 16:03:12 +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=1773849792; cv=none; b=Gi3w2TmST6iSl/ArnpGp4dQcG8SK5Dk4Ub7ZHSgANDuASZFVMCwcLC6ENbrKqlcq6yqCMftr6IgTej9m0CWqkpSjm2Ap30llARj6JwcvD7324LQQpwvxD3xA50dxmWQgIPHQxZBgmGAhc4izcOHSEiILk+TS9axoRfUvOPieMlE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1773849792; c=relaxed/simple;
	bh=z6pCfZQHgRMi00LCHsAraLfmYCfRrlpeBz/AVI5T7I4=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=FCN87y/kECGCiJEaPGjPme3O63CDnACZjwe8poHNJSbs+J8gm6c4R2jDlX9Eqv2D5EPhtSqJv+MGmP1aLKn1tGn3vq1twFkY3sZpISjKkdG1ak7RZAeLucfxTpRKiJ5LdCwbu1clT/7OA7i1e8agR1/ve4hhTD7/pZ1u4yaEUlY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WCkC2Dw9; 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="WCkC2Dw9"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F7EBC19421;
	Wed, 18 Mar 2026 16:03:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1773849792;
	bh=z6pCfZQHgRMi00LCHsAraLfmYCfRrlpeBz/AVI5T7I4=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
	b=WCkC2Dw9r1WspHcSw69znqCfke9jvbF4yXv6HEpcyW5pWAJUt/tky4Uy1vGeZ6Wbn
	 F6DO4AANOxbZYh68hsKYPy9YgG1h06epdS+C7RljXtwJrPGWt/xjMJCtdBDMGg8QkP
	 dYVwaR+WPG+k8H79oui4UGzYdJcENbx1PWPiHnnIl+qttcYjZvATjZKYsTzEPXZkTm
	 WqmvCyVxWzzputctMgPVfYNGmvvchJYGns9PamO20v/aqdE/IiAqsC65DHAq5EmkXI
	 dA0VO+nxczjRfODcTZRNHx1j8caDXl8x7iqJNDbZQI0JUNZZxGp2UnZ8F2lrEJ27Wy
	 I3fpUx6e2sUCA==
From: Thomas Gleixner <tglx@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: =?utf-8?Q?Andr=C3=A9?= Almeida <andrealmeid@igalia.com>, LKML
 <linux-kernel@vger.kernel.org>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Sebastian Andrzej Siewior
 <bigeasy@linutronix.de>, Carlos O'Donell <carlos@redhat.com>, Florian
 Weimer <fweimer@redhat.com>, Rich Felker <dalias@aerifal.cx>, Torvald
 Riegel <triegel@redhat.com>, Darren Hart <dvhart@infradead.org>, Ingo
 Molnar <mingo@kernel.org>, Davidlohr Bueso <dave@stgolabs.net>, Arnd
 Bergmann <arnd@arndb.de>, "Liam R . Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [patch 4/8] futex: Add support for unlocking robust futexes
In-Reply-To: <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>
 <20260318144758.GB3739106@noisy.programming.kicks-ass.net>
Date: Wed, 18 Mar 2026 17:03:08 +0100
Message-ID: <87ldfpm8g3.ffs@tglx>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Wed, Mar 18 2026 at 15:47, Peter Zijlstra wrote:
> On Wed, Mar 18, 2026 at 09:02:01AM +0100, Peter Zijlstra wrote:
>> 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.

What a mess...