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 1DA10C4743D for ; Fri, 4 Jun 2021 22:06:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 051B761405 for ; Fri, 4 Jun 2021 22:06:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230348AbhFDWHv (ORCPT ); Fri, 4 Jun 2021 18:07:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230041AbhFDWHs (ORCPT ); Fri, 4 Jun 2021 18:07:48 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47F16C061766; Fri, 4 Jun 2021 15:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=C6vKHA3xVyPVc71h+aqVjU0kS8fj+tvFZ8wJ00ZjTjU=; b=uinDlZpqBviYk1MDGUnitgDfDo irMekxr8ru5A1xDgBy6cZ28d41IvJbf75SoG3uHEiY1W1kwq3IUpadmjAF5Wd+Woaoh/GDsPvEBi/ J9l6yt0dJ+XKKkfM+irkF/a2ZsCpO7tlOroxXdw8S50HKPCTDml76jCCAV1lYRIBNKpc6FYbfne3t pgxWOY/Fmve7TM3kTp4fcL84JcEPJAMr8MOjdF074/bIp3rWBbaboMaUf5FNyJH/1kXac3LyKX4pH 1SEfQsMWQHGyVIFdp6Hj/fWYMiElPYB8cGQeEJNoRouOpfwu1fLQasDASeGEgCRrhIqQmlQRimtBX hfTK58Sg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lpHwM-00DdL3-6H; Fri, 04 Jun 2021 22:05:25 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id ACD64300223; Sat, 5 Jun 2021 00:05:16 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 918412BC0001B; Sat, 5 Jun 2021 00:05:16 +0200 (CEST) Date: Sat, 5 Jun 2021 00:05:16 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: "Paul E. McKenney" , Alan Stern , 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 Subject: Re: [RFC] LKMM: Add volatile_if() Message-ID: References: <20210604151356.GC2793@willie-the-truck> <20210604155154.GG1676809@rowland.harvard.edu> <20210604182708.GB1688170@rowland.harvard.edu> <20210604205600.GB4397@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Fri, Jun 04, 2021 at 02:27:49PM -0700, Linus Torvalds wrote: > On Fri, Jun 4, 2021 at 1:56 PM Paul E. McKenney wrote: > > > > The usual way to prevent it is to use WRITE_ONCE(). > > The very *documentation example* for "volatile_if()" uses that WRITE_ONCE(). > > IOW, the patch that started this discussion has this comment in it: > > +/** > + * volatile_if() - Provide a control-dependency > + * > + * volatile_if(READ_ONCE(A)) > + * WRITE_ONCE(B, 1); > + * > + * will ensure that the STORE to B happens after the LOAD of A. We do actually have uses what use a 'regular' store, and not a WRITE_ONCE(). And I think for those the added barrier() might make a difference. At the very least the perf ring-buffer case uses memcpy(). On my part I'm deeply distrusting some of the C language committee proposals I've seen regarding this stuff, and I'm maybe worrying too much, but I'd rather not have to debug anything like this when they do manage to make it go bad. On top of that, I think having the construct is good for documenting intent and possibly some of the concurrency analyzers can make use of it.