Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210928211507.20335-1-mathieu.desnoyers@efficios.com>
 <CAHk-=wg23CqjGWjjxDQ7yxrb+eF5at2KFU03GZa18Znx=+Xvow@mail.gmail.com> <1882826966.44389.1632943626923.JavaMail.zimbra@efficios.com>
In-Reply-To: <1882826966.44389.1632943626923.JavaMail.zimbra@efficios.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 29 Sep 2021 15:14:17 -0700
Message-ID: <CAHk-=wg0oguMasoc_E83MVpC61zepZGGiALVyu91BsfrYt_RiQ@mail.gmail.com>
Subject: Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc:     Will Deacon <will@kernel.org>, paulmck <paulmck@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Segher Boessenkool <segher@kernel.crashing.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Alan Stern <stern@rowland.harvard.edu>,
        Andrea Parri <parri.andrea@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        David Howells <dhowells@redhat.com>,
        j alglave <j.alglave@ucl.ac.uk>,
        luc maranget <luc.maranget@inria.fr>,
        akiyks <akiyks@gmail.com>,
        linux-toolchains <linux-toolchains@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Sep 29, 2021 at 12:27 PM Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> If we go for only using ctrl_dep() for scenarios which require it for
> documented reasons, then we would need to leave in place all the
> caveats details in Documentation/memory-barriers.txt, and document
> that in those scenarios ctrl_dep() should be used. This would be a
> starting point I guess.

So to me, it's really that starting point  that I feel needs to truly
explain the whole concept.

I'm ok with people adding more cases later (but would still want to
see a comment about exactly why that ctrl_dep() is needed), but the
initial commit is the one that I want to hold up to much higher
standards.

Those higher standards being: "there's an actual bug here" along with
documenting what exactly is going on in that particular case.

Because I do *not* want to introduce this as "ctrl_dep() documents the
control dependency".

If it's _only_ documentation, then a pure comment will do.

So to me, the only reason to actually have a ctrl_dep() macro is that
we have an actual and existing real true bug.

If the only reason for ctrl_dep() is made-up code that doesn't
actually exist, ie

        if (READ_ONCE(x))
                WRITE_ONCE(y,1);
        else
                WRITE_ONCE(y,1);

and the "READ_ONCE()" and "WRITE_ONCE()" being ordered in the face of
made-up examples like this, then ctrl_dep() shouldn't exist.

(The alternative being some "if the compiler can statically know the
direction of the 'if()'" which is I think _equally_ made up, since the
whole point of a control dependency is that it's dynamic, and no
compiler can ever statiaclly determine the direction).

See?

This is why I want to have a real actual live example for that first commit.

If we then in *other* cases add a "ctrl_dep()" for documentation
reasons, and because somebody is unsure about what the "if/else" sides
can contain and wants to make sure they cannot be merged, that's a
separate thing.

But if we can't find a single case where this truly matters and the
particular actual present bug can be shown, then it really makes me go
"is this just all theoretical for purely made up examples that aren't
realistic"?

I mean - just look at the above example of "could be done without the
'if()', and then re-ordered by the hardware". It really isn't very
realistic.

              Linus