On 20.07.24 00:11, Boqun Feng wrote: > 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. I disagree, why can't we get the specification to specify what we need? I would rather have a compiler and standard that are in sync and give us what we need, than have a standard that says we aren't allowed to do X, but compilers still allow you to do X. I don't understand why this is the case for C (I would bet this is is because of history/legacy). > 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". I think this is something that we need to very carefully evaluate on a case-by-case basis. I think that with Rust we have a clean slate and can try from the beginning to ensure that there is no compiler-but-not-specification behavior that we rely upon. AFAIK the Rust standard moves quicker than the C standard, so we might be able to influence it more easily. So what I am trying to say is: let UB be an actually useful term of forbidden behavior. If you want to convince me otherwise, I think we should talk specifics and not in this general way, since "sometimes UB is actually ok" is something that I don't want to accept in Rust as a general statement. If we have an exception, it should have a damn good reason to be an exception and then still I don't like it one bit. Can't we just ask the Rust folks to implement some compiler magic for us that achieves what we need without relying one some weird compiler quirk? --- Cheers, Benno > 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>`_. >> + > [...]
