Re: [PATCH v5 04/10] rust: sync: atomic: Add generic atomics
Andreas Hindborg <[email protected]>
| Newsgroups | dev.linux.lists.lkmm,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
"Alan Stern" <[email protected]> writes: > On Mon, Jun 30, 2025 at 11:52:35AM +0200, Andreas Hindborg wrote: >> "Boqun Feng" <[email protected]> writes: >> > Well, a non-atomic read vs an atomic read is not a data race (for both >> > Rust memory model and LKMM), so your proposal is overly restricted. >> >> OK, my mistake then. I thought mixing marked and plain accesses would be >> considered a race. I got hat from >> `tools/memory-model/Documentation/explanation.txt`: >> >> A "data race" >> occurs when there are two memory accesses such that: >> >> 1. they access the same location, >> >> 2. at least one of them is a store, >> >> 3. at least one of them is plain, >> >> 4. they occur on different CPUs (or in different threads on the >> same CPU), and >> >> 5. they execute concurrently. >> >> I did not study all that documentation, so I might be missing a point or >> two. > > You missed point 2 above: at least one of the accesses has to be a > store. When you're looking at a non-atomic read vs. an atomic read, > both of them are loads and so it isn't a data race. Ah, right. I was missing the entire point made by Boqun. Thanks for clarifying. Since what constitutes a race might not be immediately clear to users (like me), can we include the section above in the safety comment, rather than deferring to LKMM docs? Best regards, Andreas Hindborg