Hi Benno, On Wed, Jul 17, 2024 at 10:12:29PM +0000, Benno Lossin wrote: [...] > @@ -0,0 +1,246 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. highlight:: rust > + > +==================== > +Rust Safety Standard > +==================== > + > +Safe Rust code cannot have memory related bugs. This is a guarantee by the Rust compiler. Of course > +it is not without caveats: no compiler bugs, no bugs in the specification etc. But the possibly most > +important caveat is that of ``unsafe`` code. ``unsafe`` code needs to follow certain rules in order > +for safe code to enjoy the no-memory-bugs privilege. A simple example of such a rule is that > +references must be valid for the duration of their lifetime. If any rule is violated, it can lead > +to undefined behavior even in safe code! The term undefined behavior in Rust has a lot stricter > +meaning than in C or C++: UB in Rust is totally forbidden. In C one might rely on the compiler > +implementation to ensure correct code generation, but that is not the case for Rust. You can read I don't disagree with your intention here (i.e. we should seek for UB-free program), however, during the discussion on memory model, I got response like in [1]: ... they are technically wrong (violating the C standard), but practically well-tested. (and then above I added that there's good reasons for why they don't go wrong: volatile compilation strategies and reordering constraints relating volatile, inline asm, and non-atomics make it so that this almost 'has to' work, I think.) which suggests that we should rely on the compiler implementation to ensure the "correct" code generation. Basically, since LKMM relies on a few things that C standard dosen't say, e.g. votatile accesses on certain types are atomic, behaviors of asm blocks, dependencies. Let alone we have data_race() where for example, the diagnostic code accesses the shared variable out of the core synchronization design. All of the above is difficult to implement purely UB-free in Rust IIUC. Of course you could argue the ideal way is to teach Rust how to model these useful operations/patterns as non-UBs, but that's a relatively high task: Or do we want to go well beyond what happens in C, and actually define a memory model that both has the performance characteristics required by Linux, and can be defined precisely as a language-level graph-based (or ideally operational) concurrency memory model? This is a monumental task and a large open problem, and should not be on the list of blocking issues for anything that needs to get done in the next 5 years. ;) from Ralf [2]. Again, I don't want to rely on compiler's behaviors on UBs, it's just the langauge is not ready for some jobs and programmers have to be "creative". Regards, Boqun [1]: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/.E2.9C.94.20Rust.20and.20the.20Linux.20Kernel.20Memory.20Model/near/422193212 [2]: https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1221376388 > +more about UB in Rust > +`here <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>`_. > + [...]
