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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DFCAC47082 for ; Sat, 5 Jun 2021 16:25:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 642E16140C for ; Sat, 5 Jun 2021 16:25:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229933AbhFEQ1B (ORCPT ); Sat, 5 Jun 2021 12:27:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229930AbhFEQ1B (ORCPT ); Sat, 5 Jun 2021 12:27:01 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 055B3C061766 for ; Sat, 5 Jun 2021 09:25:12 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id c11so15713249ljd.6 for ; Sat, 05 Jun 2021 09:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZa60s0glSdUWznibN+YHUgSL+wdhz/USRVQvcTkA3k=; b=BQz+fRxwJrPzucEkOtxliKpTSWvi9EIwmF3SEXReAICeTz89zVE9OFvV9GV5MbYLsD QawgOFSMA9wi0wj0NsKxUp4FAEdi/eYMeMPeXWixE0CcQUC8xKaX/e2LoWw17Q6irdME KbDwe5zlt7LgNv46Z7UaR5DlXbYzZPGo7YHlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZa60s0glSdUWznibN+YHUgSL+wdhz/USRVQvcTkA3k=; b=HLGEQYpyqzjlJejeAUttRbLki1Zt1mxAAp7raYk7yBAgAN8Z8f/1ixXlyAGEFHQ8Lc VpfwkcwaQUVpXDDcIlzfhIaFmZpZkAP1u5ojZtBsoe1NkGmxTF2o88QG7aTF++RGn53J Orr8L5uQcgcsZSXHv0PCilpsGkfOW8RDW7qULycAQ0aCnT8RXy2H4ctG3NeelpQgT2CI CdlEtZ311QQvLWv7ssfenwEtX/UtaFhZnfNfxtUkKoOlmcqv2gJARcjVyL5Gr9+4aw4s 9FoBZkPEGeTHphYOsyezQg8GB6S7kziR16TtV++lzYHC+Gd/elRX2x7/iSi3WXrVFDgu Lw+g== X-Gm-Message-State: AOAM533300KdOd0HpsjS1h4y+KV5N559ojQwoWDt8FgQJ59c3FaspEig Z6h+umHI78BMmc1LF8RsbGx5S1mFNrqD10Yaisg= X-Google-Smtp-Source: ABdhPJxBYDxaO/gaIxVD3uvunlHFAvmek++MVuvGuI6umjun7arUmgqA3yM56/pYlGE4uGjrZeMIow== X-Received: by 2002:a2e:b4b4:: with SMTP id q20mr1709209ljm.27.1622910311295; Sat, 05 Jun 2021 09:25:11 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id z139sm990500lfc.150.2021.06.05.09.25.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 09:25:11 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id f11so18693151lfq.4 for ; Sat, 05 Jun 2021 09:25:10 -0700 (PDT) X-Received: by 2002:a05:6512:987:: with SMTP id w7mr6239078lft.41.1622910310532; Sat, 05 Jun 2021 09:25:10 -0700 (PDT) MIME-Version: 1.0 References: <20210604134422.GA2793@willie-the-truck> <20210604151356.GC2793@willie-the-truck> <20210604155154.GG1676809@rowland.harvard.edu> <20210604182708.GB1688170@rowland.harvard.edu> <20210605031403.GA1701165@rowland.harvard.edu> In-Reply-To: <20210605031403.GA1701165@rowland.harvard.edu> From: Linus Torvalds Date: Sat, 5 Jun 2021 09:24:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: Alan Stern Cc: Peter Zijlstra , Will Deacon , "Paul E. McKenney" , Andrea Parri , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Linux Kernel Mailing List , linux-toolchains@vger.kernel.org, linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Jun 4, 2021 at 8:14 PM Alan Stern wrote: > > > > > then I could in theory see teh compiler doing that WRITE_ONCE() as > > some kind of non-control dependency. > > This may be a minor point, but can that loophole be closed as follows? Note that it's actually entirely sufficient to have the barrier just on one side. I brought it up mainly as an oddity, and that it can result in the compiler generating different code for the two different directions. The reason that it is sufficient is that with the barrier in place (on either side), the compiler really can't do much. It can't join either of the sides, because it has to do that barrier on one side before any common code. In fact, even if the compiler decides to first do a conditional call just around the barrier, and then do any common code (and then do _another_ conditional branch), it still did that conditional branch first, and the problem is solved. The CPU doesn't care, it will have to resolve the branch before any subsequent stores are finalized. Of course, if the compiler creates a conditional call just around the barrier, and the barrier is empty (like we do now), and the compiler leaves no mark of it in the result (like it does seem to do for empty asm stataments), I could imagine some optimizing assembler (or linker) screwing things up for us, and saying "a conditional branch to the next instruction can just be removed). At that point, we've lost again, and it's a toolchain issue. I don't think that issue can currently happen, but it's an example of yet another really subtle problem that *could* happen even if *we* do everything right. I also do not believe that any of our code that has this pattern would have that situation where the compiler would generate a branch over just the barrier. It's kind of similar to Paul's example in that sense. When we use volatile_if(), the two sides are very very different entirely regardless of the barrier, so in practice I think this is all entirely moot. Linus