From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95B14C433F5 for ; Thu, 14 Oct 2021 02:14:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D64E610CB for ; Thu, 14 Oct 2021 02:14:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbhJNCQh (ORCPT ); Wed, 13 Oct 2021 22:16:37 -0400 Received: from netrider.rowland.org ([192.131.102.5]:36745 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S229798AbhJNCQh (ORCPT ); Wed, 13 Oct 2021 22:16:37 -0400 Received: (qmail 910485 invoked by uid 1000); 13 Oct 2021 22:14:31 -0400 Date: Wed, 13 Oct 2021 22:14:31 -0400 From: Alan Stern To: "Paul E. McKenney" Cc: Florian Weimer , Linus Torvalds , Mathieu Desnoyers , Segher Boessenkool , Will Deacon , Peter Zijlstra , linux-kernel , Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , j alglave , luc maranget , akiyks , linux-toolchains , linux-arch Subject: Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency Message-ID: <20211014021431.GA910341@rowland.harvard.edu> References: <20210928211507.20335-1-mathieu.desnoyers@efficios.com> <87lf3f7eh6.fsf@oldenburg.str.redhat.com> <20210929174146.GF22689@gate.crashing.org> <2088260319.47978.1633104808220.JavaMail.zimbra@efficios.com> <871r54ww2k.fsf@oldenburg.str.redhat.com> <87y271yo4l.fsf@mid.deneb.enyo.de> <20211014000104.GX880162@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211014000104.GX880162@paulmck-ThinkPad-P17-Gen-1> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Oct 13, 2021 at 05:01:04PM -0700, Paul E. McKenney wrote: > On Sun, Oct 10, 2021 at 04:02:02PM +0200, Florian Weimer wrote: > > * Linus Torvalds: > > > > > On Fri, Oct 1, 2021 at 9:26 AM Florian Weimer wrote: > > >> > > >> Will any conditional branch do, or is it necessary that it depends in > > >> some way on the data read? > > > > > > The condition needs to be dependent on the read. > > > > > > (Easy way to see it: if the read isn't related to the conditional or > > > write data/address, the read could just be delayed to after the > > > condition and the store had been done). > > > > That entirely depends on how the hardware is specified to work. And > > the hardware could recognize certain patterns as always producing the > > same condition codes, e.g., AND with zero. Do such tests still count? > > It depends on what the specification says. > > > > What I really dislike about this: Operators like & and < now have side > > effects, and is no longer possible to reason about arithmetic > > expressions in isolation. > > Is there a reasonable syntax that might help with these issues? > > Yes, I know, we for sure have conflicting constraints on "reasonable" > on copy on this email. What else is new? ;-) > > I could imagine a tag of some sort on the load and store, linking the > operations that needed to be ordered. You would also want that same > tag on any conditional operators along the way? Or would the presence > of the tags on the load and store suffice? Here's a easy cop-out. Imagine a version of READ_ONCE that is equivalent to: a normal READ_ONCE on TSO architectures, a load-acquire on more weakly ordered architectures. Call it READ_ONCE_FOR_COND, for the sake of argument. Then as long as people are careful to use READ_ONCE_FOR_COND when loading the values that a conditional expression depends on, and WRITE_ONCE for the important stores in the branches of the "if" statement, all architectures will have the desired ordering. (In fact, if there are multiple loads involved in the condition then only the last one has to be READ_ONCE_FOR_COND; the others can just be READ_ONCE.) Of course, this is not optimal on non-TSO archictecture. That's why I called it a cop-out. But at least it is simple and easy. Alan Stern