A memory model for Rust code in the kernel

> He suggested that, perhaps, the kernel's memory model could be rebuilt on top of C or C++ atomic operations, at which point supporting the Rust model would be easier. That seems unlikely to happen, though, given the strong opposition from Linus Torvalds to any such change.

Torvalds is right on this issue. I‘m an avid rust fan and use the language every day. Rust has the job to adapt to the kernel, not the other way around. Imagine if instead on working on „panic-free“ rust for the kernel, maintainers would call for the kernel to just crash.

If rust can not sufficiently adapt to the way of the kernel, either the language needs to change or the experiment needs to be considered as a failed one.

> Without that caching, performance would slow to a crawl, severely impacting the production, delivery, and consumption of cat videos, phishing spam, and cryptocurrency scams. This prospect is seen as a bad thing.

Okay, that's a cheap joke, but it got a chuckle from me.

I wouldn't include atomics and memory barriers in the "fearless concurrency" category of Rust. Is there really a large enough body of third-party code to worry about compatibility?

As for Linus's complaint that compilers aren't perfect, I've seen many bugs over the years with this style of code. A missing memory barrier doesn't exactly stand out. Maybe Linux has a better track record, but I would love to push as much of this as possible into the hands of a "pre-reliable" compiler, where a bug can be fixed once.

It seems like they're taking a reasonable and measured approach to start with a small surface area, which bodes well for the future of Rust in Linux.

For anyone else also trying to wrap their head around the Clang C++ optimization/concurrency bug [1]:

The crux of it is that deleting *p = i prior to foo(i, a) is illegal, because it would lose the guarantee that *a == N implies *p == N in another thread, when X == p.

(i.e. After the optimization, it becomes possible for other threads to observe *p != N even when *a == N, but this should be impossible according to the original code.)

The general issue is that loop invariant code motion (LICM) optimization would also be required to hoist out any threading-related guarantees (like memory fences) from loops, not just the data as it appears to a single thread.

[1] https://github.com/llvm/llvm-project/issues/64188

It sounds like Torvalds has finally found a way to delay the Rust developers taking over the kernel.