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: <6B0A9441-5DB5-476B-B94C-F0BDF1505095@joelfernandes.org>
Date:   Fri, 4 Aug 2023 23:47:07 +0800
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-Transfer-Encoding: quoted-printable
Message-Id: <E6EDDDE7-5D59-4284-931E-23E3636C8CF0@gmail.com>
References: <D3D65E05-AC98-43EA-8B66-CA63E94C1C80@gmail.com>
 <6B0A9441-5DB5-476B-B94C-F0BDF1505095@joelfernandes.org>
To:     Joel Fernandes <joel@joelfernandes.org>
Precedence: bulk

>=20
>>>=20
>>>>>> But the example here is different,
>>>>>=20
>>>>> That is intentional. Wills discussion partially triggered this. =
Though I am wondering
>>>>> if we should document that as well.
>>>>>=20
>>>>>> the compiler can not use the value loaded from line 5
>>>>>> unless the compiler can deduce that the tmp is equals to p in =
which case the address dependency
>>>>>> doesn=E2=80=99t exist anymore.
>>>>>>=20
>>>>>> What am I missing here?
>>>>>=20
>>>>> Maybe you are trying to rationalize too much that the sequence =
mentioned cannot result
>>>>> in a counter intuitive outcome like I did?
>>>>>=20
>>>>> 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.
>>>>=20
>>>> Well, IIUC, according to the C standard, the compiler can do =
anything if there is a data race (undefined behavior).
>>>>=20
>>>> However, what if a write is not protected with WRITE_ONCE and the =
read 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.
>>>=20
>>> 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
>>=20
>> 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
>> However, the kernel consider the volatile access to be atomic, right?
>>=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
> I am actually a bit lost with what you are trying to say.  Are you =
saying that mixing
> plain accesses with marked accesses is an acceptable practice?=20


I=E2=80=99m trying to say that sometimes data race is fine, that=E2=80=99s=
 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=20
deduces that the value of gp is always the same.


>=20
> I would like others to weight in as well since I am not seeing what =
Alan is suggesting.
> AFAICS, in the absence of barrier(), any optimization caused by plain =
access
> makes it a bad practice to mix it.
>=20
> Thanks,
>=20
> - Joel
>=20
>=20
>=20
>>=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