Re: Allow data races on some read/write operations

[comex <comexk@gmail.com>]

> On Mar 4, 2025, at 11:03 AM, Ralf Jung <post@ralfj.de> wrote:
> 
> Those already exist in Rust, albeit only unstably: <https://doc.rust-lang.org/nightly/std/intrinsics/fn.volatile_copy_memory.html>. However, I am not sure how you'd even generate such a call in C? The standard memcpy function is not doing volatile accesses, to my knowledge.

The actual memcpy symbol that exists at runtime is written in assembly, and should be valid to treat as performing volatile accesses.

But both GCC and Clang special-case the memcpy function.  For example, if you call memcpy with a small constant as the size, the optimizer will transform the call into one or more regular loads/stores, which can then be optimized mostly like any other loads/stores (except for opting out of alignment and type-based aliasing assumptions).  Even if the call isn’t transformed, the optimizer will still make assumptions.  LLVM will automatically mark memcpy `nosync`, which makes it undefined behavior if the function “communicate[s] (synchronize[s]) with another thread”, including through “volatile accesses”. [1]

However, these optimizations should rarely trigger misbehavior in practice, so I wouldn’t be surprised if Linux had some code that expected memcpy to act volatile…

But I’m not familiar enough with the codebase to know whether such code actually exists, or where.

(Incidentally, there is a compiler flag to turn the memcpy special-casing off, -fno-builtin.  I pretty much expected that Linux used it.  But I just checked, and it doesn’t.)

For Rust, I don’t know why we haven’t exposed volatile_copy_memory yet.  All I can find are some years-old discussions with no obvious blockers.  I guess nobody has cared enough.  There is also a somewhat stagnant RFC for *atomic* memcpy. [2]

[1] https://llvm.org/docs/LangRef.html, search for 'nosync'
[2] https://github.com/rust-lang/rfcs/pull/3301