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 78D45C433EF for ; Thu, 14 Oct 2021 22:36:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 57B2C6109E for ; Thu, 14 Oct 2021 22:36:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231309AbhJNWjA (ORCPT ); Thu, 14 Oct 2021 18:39:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230330AbhJNWi7 (ORCPT ); Thu, 14 Oct 2021 18:38:59 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD7D0C061570 for ; Thu, 14 Oct 2021 15:36:53 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id i24so32284509lfj.13 for ; Thu, 14 Oct 2021 15:36:53 -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=oPuxOfPoEn2w+Vy6YtWqvZyYsB0r4ReZCNxVMrkb8QI=; b=TU2N5ITK3xVvoWLOxg0QxSdXuTND/1UVb8D9kq7fbac/6VC+lbImYzJlzwGBaDf5Pi 1jEErQguvYRKtAArQG03jv4A/g1xPWpJLfs42JrKGBOTus1dB6eJozNJOOcZh974rGLb bnRyUJRcXby9bIILD4PGb6QWwfZdO2Q7jF3rY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oPuxOfPoEn2w+Vy6YtWqvZyYsB0r4ReZCNxVMrkb8QI=; b=I/+8GZFIkHJbV2LEfenGoO7J5FsurbF6VlkersDL5dKSPDRZxv8ruKzThTqLCI9xjK J4oiVHvh4EjUM3XPDAVNXfAb4oMX+6DrTD7nzMvEdujnYYwLdR6uE0rIxoT2PvIZ273c eyoGqwRGV6QO65vladBhMhfEKCiEV9rBaM3QGZVJwPKknwLiDaoVB/ulOY9Ncl++xpW/ aOFNtdnQYsMKj2ZBI4wX9nOqp1xVaV+R9tT3IuCablUF5nG+Zv6sODKn619rlpw3uSAk gdZgTShfS+eDBZKeqba/pOL8wHEV2bwiYkELqo2NzX8MoF1IY8xJWU+UdHlhTGgc8oXL NlnQ== X-Gm-Message-State: AOAM530f0lf1moLNHoVZ4ryiiB7w8131iaGFtvUMVvx61t1799XOfN7X pdhIgqov1bo6uV1XI7p+IQu6m64CIHjIP0YU X-Google-Smtp-Source: ABdhPJzZ0HUBgrF9lAk6fIlu9KWm/uFfbugC5CNP7Tv086nuMqmdgBg41QQVBo3yx1aplkkSsmT4kg== X-Received: by 2002:a05:6512:1284:: with SMTP id u4mr16268lfs.614.1634251011745; Thu, 14 Oct 2021 15:36:51 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id p15sm335954lfe.1.2021.10.14.15.36.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 15:36:49 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id y26so33412028lfa.11 for ; Thu, 14 Oct 2021 15:36:45 -0700 (PDT) X-Received: by 2002:a05:6512:398a:: with SMTP id j10mr7595767lfu.402.1634251004791; Thu, 14 Oct 2021 15:36:44 -0700 (PDT) MIME-Version: 1.0 References: <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> <87lf2v61k7.fsf@mid.deneb.enyo.de> <20211014162311.GD880162@paulmck-ThinkPad-P17-Gen-1> <87o87r4gfp.fsf@mid.deneb.enyo.de> <20211014210959.GJ880162@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: <20211014210959.GJ880162@paulmck-ThinkPad-P17-Gen-1> From: Linus Torvalds Date: Thu, 14 Oct 2021 18:36:28 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency To: "Paul E. McKenney" Cc: Florian Weimer , Mathieu Desnoyers , Segher Boessenkool , Will Deacon , Peter Zijlstra , linux-kernel , Alan Stern , Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , j alglave , luc maranget , akiyks , linux-toolchains , linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 14, 2021 at 5:10 PM Paul E. McKenney wrote: > > In all the weakly ordered architectures I am aware of, spilling to > the stack and reloading preserves the ordering. The ordering from > the initial load to the spill is an assembly-language data dependency, > the ordering from the spill to the reload is single-variable SC, and > the ordering beyond that is the original control dependency. I think the thing about a control dependency is that any way to optimize it differently only strengthens it. That was very different from the problems we had with describing the RCU dependencies - they were data dependencies, and if they could ever be turned into control dependencies, they would have been weakened. But the only way to really weaken a control dependency and the write behind it is to get rid of it entirely. So turning it into a data dependency (by turning the conditional into a 'select' instruction, for example) only makes it stronger. And no amount of register spilling or data movement any other way makes any difference. That's why all the examples of what could go wrong were about same code on both sides of the conditional, which allowed removing the conditional entirely (or at least moving parts of the "protected" code to before it. (The other way to remove the conditional is to just optimize away the conditional itself, but that's defeated by "READ_ONCE()" being part of the source of the conditional, and any data or control dependency from that fundamental "the compiler cannot remove this logic" is always sufficient). So I really don't think this is even about "any weakly ordered architecture". I think this is fundamentally about causality. You simply cannot make a conditional write visible before the condition has been resolved, and resolving the condition requires the read to have happened. This is not open to "speculation". Not by hardware, not by compilers. There are only two ways you can break this fundamental construct: - outright bugs - a perfect oracle And honestly, if you have a perfect oracle, you're better off making money playing the lotto than you would ever be doing hardware or software development, so that second option isn't really even interesting. Linus