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 76C8AC4743D for ; Fri, 4 Jun 2021 22:20:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5304661405 for ; Fri, 4 Jun 2021 22:20:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229774AbhFDWW1 (ORCPT ); Fri, 4 Jun 2021 18:22:27 -0400 Received: from mail-lj1-f182.google.com ([209.85.208.182]:42847 "EHLO mail-lj1-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbhFDWW1 (ORCPT ); Fri, 4 Jun 2021 18:22:27 -0400 Received: by mail-lj1-f182.google.com with SMTP id a4so13435653ljq.9 for ; Fri, 04 Jun 2021 15:20:30 -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=pPBKYL6ZDlO98XpQWgE0P5mOmUKMMrEHZWBoQUeXOIzK2JF2dfvYwWvMbbTvTHi647 /Qj3Svf1tFeBM+ZZTdVZEkw5DG2oO/lug98Me4Sh2v/gRDBdfWbo2HXa54ng3xGXOhhN tI2raEYh9YuuvmGBkjhLmjBAtmPf4TYfChhomKxC3Nb8O9Y9N0a8iYuz8r+B0/9j5Kc9 0/QSGyUnU5Qu4YUgUicvZ1MpmM4dTlJADPUmf02e3ppJw44XVpO6aUgLhNmj4V9wyRs2 7If38djf0PokPHiSpOqASnld1Y5eL6aXq1NI6hyUfDTJy7JcBwwPIx8Pa3sVuHvFGYoo Rxmw== X-Gm-Message-State: AOAM532TPgDTaP76vcJ5XORL/TnKnzh4Drd4yCuhJlycJ4pO90VN9NPI vVMbh1W1NHet/NjrIUXvpoT4FEavLyepWUCa94Y= X-Google-Smtp-Source: ABdhPJzyIR5FO9W0K88Pcm0KSl8JxNDzco8yGVbNMqo1a0QkXsmA+YrtVbD0M8wMWJrNRBU9pJWrVA== X-Received: by 2002:a05:651c:514:: with SMTP id o20mr5071281ljp.201.1622845169179; Fri, 04 Jun 2021 15:19:29 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id u5sm720198lfk.237.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-f176.google.com with SMTP id e11so13419750ljn.13 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-toolchains@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