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 CAA94C4743C for ; Fri, 4 Jun 2021 22:20:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AE37A613E4 for ; Fri, 4 Jun 2021 22:20:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231199AbhFDWWd (ORCPT ); Fri, 4 Jun 2021 18:22:33 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:38829 "EHLO mail-lj1-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbhFDWWb (ORCPT ); Fri, 4 Jun 2021 18:22:31 -0400 Received: by mail-lj1-f170.google.com with SMTP id a4so13465201ljd.5 for ; Fri, 04 Jun 2021 15:20:29 -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=+9zFBMvnldr+a2Bn098Bq6btluKTz9/gtI3L8L3G704=; b=ON4ziKiRp5LVq4JfVNVftECbm0Jxb1CFgpD63zSOqLcI1y/jw+2eSrTArKHg8kOxFi GJfAJLgbireiKAUxlonVH76df7ajATcwEE9AfwbclT3V9zSZ/V5X7fjdpTaZk9/8XbmN dZdg+6BU30M/38YSvOFl4iwDOiyXpBw10D2dc= 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=+9zFBMvnldr+a2Bn098Bq6btluKTz9/gtI3L8L3G704=; b=CZU1VgL3goajdBg4FHBbVvnq3Ol2HHdlsNLFXLpe99Br0AwMeGbg1XT1bLMBXNW/xy 4+8WiRFP809Id8AZF48DttZo7yp75Xs357bDrPl40e9CpYWm6Um/WLzzl6UGAfX0mRxv qYBg+YMkiQw4jWRN9g+Jo8QjsTlGG/GHRkKIGq3CF5wOn7SIY1mg7u4I8fsT6INQ5tKq h24yFfmeZZ8LN8Y3eCLeSuL2eoZvYgZM6SFgHySAXsidHTXRwhg0H7C5cAVzV9Yp5HLW TqKWR15S7u7P8v1tKL4K3Y5K6fU32fXV2dv7UbjpultMKQV3TVx62GgPTg6MogzMm1bj j9hw== X-Gm-Message-State: AOAM530WfFJX4KgmAGP13vVUUsD13tA9sEfYUfdjcS1a+IMokMvAVEDj NEly14nEjsCrCo7lhh1m98yfbbjpWHAXLKTawXk= X-Google-Smtp-Source: ABdhPJyOsUz+18w+njDVesf5qUwFCx5F5SMYO24lLObuE5y9b5wfJCr37O1eta2IwJWRlQZO+Mys1A== X-Received: by 2002:a2e:2f09:: with SMTP id v9mr4918367ljv.152.1622845168599; Fri, 04 Jun 2021 15:19:28 -0700 (PDT) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id q19sm718172lff.281.2021.06.04.15.19.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 15:19:27 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id u22so13433558ljh.7 for ; Fri, 04 Jun 2021 15:19:27 -0700 (PDT) X-Received: by 2002:a2e:b60d:: with SMTP id r13mr5244550ljn.220.1622845167131; Fri, 04 Jun 2021 15:19:27 -0700 (PDT) MIME-Version: 1.0 References: <20210604151356.GC2793@willie-the-truck> <20210604155154.GG1676809@rowland.harvard.edu> <20210604182708.GB1688170@rowland.harvard.edu> <20210604205600.GB4397@paulmck-ThinkPad-P17-Gen-1> <20210604214010.GD4397@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: <20210604214010.GD4397@paulmck-ThinkPad-P17-Gen-1> From: Linus Torvalds Date: Fri, 4 Jun 2021 15:19:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: "Paul E. McKenney" Cc: Alan Stern , Peter Zijlstra , Will Deacon , 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-kernel@vger.kernel.org On Fri, Jun 4, 2021 at 2:40 PM Paul E. McKenney wrote: > > Here is one use case: > > volatile_if(READ_ONCE(A)) { > WRITE_ONCE(B, 1); > do_something(); > } else { > WRITE_ONCE(B, 1); > do_something_else(); > } > > With plain "if", the compiler is within its rights to do this: > > tmp = READ_ONCE(A); > WRITE_ONCE(B, 1); > if (tmp) > do_something(); > else > do_something_else(); > > On x86, still no problem. But weaker hardware could now reorder the > store to B before the load from A. With volatile_if(), this reordering > would be prevented. But *should* it be prevented? For code like the above? I'm not really seeing that the above is a valid code sequence. Sure, that "WRITE_ONCE(B, 1)" could be seen as a lock release, and then it would be wrong to have the read of 'A' happen after the lock has actually been released. But if that's the case, then it should have used a smp_store_release() in the first place, not a WRITE_ONCE(). So I don't see the above as much of a valid example of actual READ/WRITE_ONCE() use. If people use READ/WRITE_ONCE() like the above, and they actually depend on that kind of ordering, I think that code is likely wrong to begin with. Using "volatile_if()" doesn't make it more valid. Now, part of this is that I do think that in *general* we should never use this very suble load-cond-store pattern to begin with. We should strive to use more smp_load_acquire() and smp_store_release() if we care about ordering of accesses. They are typically cheap enough, and if there's much of an ordering issue, they are the right things to do. I think the whole "load-to-store ordering" subtle non-ordered case is for very very special cases, when you literally don't have a general memory ordering, you just have an ordering for *one* very particular access. Like some of the very magical code in the rw-semaphore case, or that smp_cond_load_acquire(). IOW, I would expect that we have a handful of uses of this thing. And none of them have that "the conditional store is the same on both sides" pattern, afaik. And immediately when the conditional store is different, you end up having a dependency on it that orders it. But I guess I can accept the above made-up example as an "argument", even though I feel it is entirely irrelevant to the actual issues and uses we have. Linus