From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 6689E5644E for ; Mon, 18 Mar 2024 16:48:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710780542; cv=none; b=q91R6tFom2+dO1cR25oyssZRcrOYJvcX4l1cLqVYOtSkWgyQMLOPxhg+1UN8k7gctx3lqCmr4r0UVAMyBGFz8f8KlKWxeANrZMkIcbXgxsZdvdufThIkuDx/yxAj2G06BRpkIJ/bhPX0HKACjqAK9NzSH50VYjygXqAb5mAbMDA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710780542; c=relaxed/simple; bh=ZUvlr4NfEo8YD28xQJfWHf1RCWx9gP2i9qaNnQ+2Gd0=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=aObGnZ3VhNyTEVICodb1ienrdnorfNbo8wgZBlJsmAwezOeytw1GhHXKQJM+HC9bVG1F00BjyXjrzUx3VwW1zL46AxuOCtMIpMBdixbH5es6kBDUMdcq2Xkf7jJQjWzFJmfLa1KPb4JBG9wOWoqPhnjQRYd3pfanMjggxmrm73U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=QMinApV9; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="QMinApV9" Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 42IGmki91156837 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 18 Mar 2024 09:48:47 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 42IGmki91156837 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024031401; t=1710780527; bh=P5vVCLGEL8EcwtIRsCJyZG9BWF4EqUcVrox3QC0pt3o=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=QMinApV9OvVkK1y1xHCJfhA0LnwqaXuLRXmAbOFAntc2sxsWD8M3JZQLVw7YaC1K7 Bl7pBmDbnGMXFwWgJRQXzDzQ5AzvSjXG/TIcufwuC/x+QRKq7bTSkClb42xEqJzuBR VEuIUrcvk02GJiYMZInrgPkp1VqzROdTdfrtLu3+SQJYzPHsQfPtS4/sA3wW2trNJa vhyyrmxFgJWY8k5O8+JH5wYDQIeEl8b1UmK3hI6j6sf9NKuqHVW2XMHwTdbD/H5OoS jA8jG1FxrttI2l7OoMTt1JaL27hdgxwDElTywbddV0Os176G41wq694XUC/AsTt9Rm FhWhhRt3+bYoA== Date: Mon, 18 Mar 2024 09:48:43 -0700 From: "H. Peter Anvin" To: Linus Torvalds , paulmck@kernel.org CC: linux-toolchains@vger.kernel.org, peterz@infradead.org, rostedt@goodmis.org, gregkh@linuxfoundation.org, keescook@chromium.org Subject: Re: A few proposals, this time from the C++ standards committee User-Agent: K-9 Mail for Android In-Reply-To: References: <83f5e119-6e32-415a-a1c8-8e6b0bd11a75@paulmck-laptop> Message-ID: <1E607720-D858-4969-BCFB-72819425F115@zytor.com> Precedence: bulk X-Mailing-List: linux-toolchains@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 March 18, 2024 9:32:55 AM PDT, Linus Torvalds wrote: >[ Final note on this, I hope ] > >On Sun, 17 Mar 2024 at 13:50, Linus Torvalds > wrote: >> >> Now, on x86, this happens automatically, because even if you move the >> "*p =3D N" down to after the function call, all stores are releases, so >> by the time 'p' becomes visible to anybody else, you are guaranteed to >> see the right ordering=2E > >Actually, I take that back=2E > >Even x86 (and s390) can see problems from the "move store past a >function call" issue, although they require more effort by the >compiler=2E > >Because while it is true that every store is a release on x86, and as >such any store that exposes the address to another CPU will >automatically have done the release that also guarantees that the >value 'N' is visible to any other thread (and then the acquire will >guarantee that the other end sees the right value), that doesn't >necessarily fix the problem=2E > >Why? Once the compiler has missed the original memory barrier (that >was in the function that it moved the store past), the compiler could >end up doing further store movement, and simply generate the code to >do the '*p =3D N' store after exposing the address=2E > >At that point, even a strong memory ordering won't help - although it >would probably make the problem easier to spot as a human (and would >probably make it easier to trigger too, since then things like >interrupts, preemption or single-stepping would also make the window >to see it much much bigger)=2E > >So x86 wouldn't be immune to this, it would just require more >reordering by the compiler (which might in turn require that the >function was inlined in order to give that re-ordering possibility, of >course)=2E > > Linus Hardware memory order doesn't mean anything if the compiler is the one mes= sing it up=2E=2E=2E