Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <D3D65E05-AC98-43EA-8B66-CA63E94C1C80@gmail.com>
 <6B0A9441-5DB5-476B-B94C-F0BDF1505095@joelfernandes.org> <E6EDDDE7-5D59-4284-931E-23E3636C8CF0@gmail.com>
In-Reply-To: <E6EDDDE7-5D59-4284-931E-23E3636C8CF0@gmail.com>
From:   Joel Fernandes <joel@joelfernandes.org>
Date:   Fri, 4 Aug 2023 12:15:42 -0400
Message-ID: <CAEXW_YQez6yNzwLXg_mbKN9pZV1=EzO7-X5s5GLj_F34P6c+kw@mail.gmail.com>
Subject: Re: [PATCH 1/2] docs: rcu: Add cautionary note on plain-accesses to requirements
To:     Alan Huang <mmpgouride@gmail.com>
Cc:     linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
        Will Deacon <will@kernel.org>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Josh Triplett <josh@joshtriplett.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Zqiang <qiang.zhang1211@gmail.com>,
        Jonathan Corbet <corbet@lwn.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Aug 4, 2023 at 11:47=E2=80=AFAM Alan Huang <mmpgouride@gmail.com> w=
rote:
>
> >
> >>>
> >>>>>> But the example here is different,
> >>>>>
> >>>>> That is intentional. Wills discussion partially triggered this. Tho=
ugh I am wondering
> >>>>> if we should document that as well.
> >>>>>
> >>>>>> the compiler can not use the value loaded from line 5
> >>>>>> unless the compiler can deduce that the tmp is equals to p in whic=
h case the address dependency
> >>>>>> doesn=E2=80=99t exist anymore.
> >>>>>>
> >>>>>> What am I missing here?
> >>>>>
> >>>>> Maybe you are trying to rationalize too much that the sequence ment=
ioned cannot result
> >>>>> in a counter intuitive outcome like I did?
> >>>>>
> >>>>> The point AFAIU is not just about line 10 but that the compiler can=
 replace any of the
> >>>>> lines after the plain access with the cached value.
> >>>>
> >>>> Well, IIUC, according to the C standard, the compiler can do anythin=
g if there is a data race (undefined behavior).
> >>>>
> >>>> However, what if a write is not protected with WRITE_ONCE and the re=
ad is marked with READ_ONCE?
> >>>> That=E2=80=99s also a data race, right? But the kernel considers it =
is Okay if the write is machine word aligned.
> >>>
> >>> Yes, but there is a compiler between the HLL code and what the
> >>> processor sees which can tear the write. How can not using
> >>> WRITE_ONCE() prevent store-tearing? See [1]. My understanding is that
> >>> it is OK only if the reader did a NULL check. In that case the torn
> >>
> >> Yes, a write-write data race where the value is the same is also fine.
> >>
> >> But they are still data race, if the compiler is within its right to d=
o anything it likes (due to data race),
> >> we still need WRITE_ONCE() in these cases, though it=E2=80=99s semanti=
cally safe.
> >>
> >> IIUC, even with _ONCE(), the compiler is within its right do anything =
according to the standard (at least before the upcoming C23), because the s=
tandard doesn=E2=80=99t consider a volatile access to be atomic.
> >>
> >> However, the kernel consider the volatile access to be atomic, right?
> >>
> >> BTW, line 5 in the example is likely to be optimized away. And yes, th=
e compiler can cache the value loaded from line 5 from the perspective of u=
ndefined behavior, even if I believe it would be a compiler bug from the pe=
rspective of kernel.
> >
> > I am actually a bit lost with what you are trying to say.  Are you sayi=
ng that mixing
> > plain accesses with marked accesses is an acceptable practice?
>
>
> I=E2=80=99m trying to say that sometimes data race is fine, that=E2=80=99=
s why we have the data_race().
>
> Even if the standard says data race results in UB.
>
> And IMHO, the possible data race at line 5 in this example is also fine, =
unless the compiler
> deduces that the value of gp is always the same.

IMHO, no one is saying it is not "fine". As in, such behavior is
neither a compiler nor strictly a kernel bug.  More a wtf that the
programmer should know off (does not hurt to know).

I will rest my case with AlanH pending any input from people who know
more than me. If there is a better way to represent such matters in
the docs, I am happy to make changes to this patch.

Cheers,

 - Joel