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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Subject: Re: [PATCH 1/2] docs: rcu: Add cautionary note on plain-accesses to
 requirements
From:   Alan Huang <mmpgouride@gmail.com>
In-Reply-To: <f5652b1a-de71-4881-8825-fedd73544f54@paulmck-laptop>
Date:   Sat, 5 Aug 2023 00:33:03 +0800
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
        Will Deacon <will@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-Transfer-Encoding: quoted-printable
Message-Id: <DFBE4F45-BF8B-4267-93C7-B085A88BE356@gmail.com>
References: <A272EB21-28F9-4FFE-A3BB-6689807CC3ED@gmail.com>
 <148CE02E-BBEC-4D30-9C75-6632A110FFC0@joelfernandes.org>
 <E96297CF-6C81-4BB5-BA5A-6734F6B629F4@gmail.com>
 <CAEXW_YRXA3j3k9VRuZJ7d=yo6__TRpeE6igrQ+GEZiyKtFmUOQ@mail.gmail.com>
 <D3D65E05-AC98-43EA-8B66-CA63E94C1C80@gmail.com>
 <f5652b1a-de71-4881-8825-fedd73544f54@paulmck-laptop>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Precedence: bulk


>> Yes, a write-write data race where the value is the same is also =
fine.
>>=20
>> But they are still data race, if the compiler is within its right to =
do anything it likes (due to data race),
>> we still need WRITE_ONCE() in these cases, though it=E2=80=99s =
semantically safe.
>>=20
>> IIUC, even with _ONCE(), the compiler is within its right do anything =
according to the standard (at least before the upcoming C23), because =
the standard doesn=E2=80=99t consider a volatile access to be atomic.
>=20
> Volatile accesses are not specified very well in the standard.  =
However,
> as a practical matter, compilers that wish to be able to device =
drivers
> (whether in kernels or userspace applications) must compile those =
volatile
> accesses in such a way to allow reliable device drivers to be written.
>=20
>> However, the kernel consider the volatile access to be atomic, right?
>=20
> The compiler must therefore act as if a volatile access to an aligned
> machine-word size location is atomic.  To see this, consider accesses
> to memory that is shared by a device driver and that device's =
firmware,
> both of which are written in either C or C++.

I learned these things a few months ago. But still thank you!

The real problem is that there may be a data race at line 5, so Joel is =
correct that the compiler
can cache the value loaded from line 5 according to the standard given =
that the standard says that
a data race result in undefined behavior, so the compiler might be =
allowed to do anything. But from the
perspective of the kernel, line 5 is likely a diagnostic read, so it=E2=80=
=99s fine without READ_ONCE() and the
compiler is not allowed to cache the value.

This situation is like the volatile access.

Am I missing something?

>=20
> Does that help?
>=20
> Thanx, Paul
>=20
>> BTW, line 5 in the example is likely to be optimized away. And yes, =
the compiler can cache the value loaded from line 5 from the perspective =
of undefined behavior, even if I believe it would be a compiler bug from =
the perspective of kernel.
>>=20
>>> result will not change the semantics of the program. But otherwise,
>>> that's bad.
>>>=20
>>> [1] https://lwn.net/Articles/793253/#Store%20Tearing
>>>=20
>>> thanks,
>>>=20
>>> - Joel
>>>=20
>>>=20
>>>>=20
>>>>>=20
>>>>> Thanks.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>> +plain accesses of a memory location with rcu_dereference() of =
the same memory
>>>>>>> +location, in code involved in a data race.
>>>>>>> +
>>>>>>> In short, updaters use rcu_assign_pointer() and readers use
>>>>>>> rcu_dereference(), and these two RCU API elements work together =
to
>>>>>>> ensure that readers have a consistent view of newly added data =
elements.
>>>>>>> --
>>>>>>> 2.41.0.585.gd2178a4bd4-goog