3 ms·

A memory model for Rust code in the kernel

114 points by jmillikin 3y ago

PoignardAzur 3y ago
> 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.
- bru3s 3y ago
  Very reminiscent of Adam Douglas' writing style (or Terry Pratchett FWIW)
  - gostsamo 3y ago
    > This prospect is seen as a bad thing. This is almost word for word lifted from The Hitchhiker's Guide to the Galaxy.
    - zellyn 3y ago
      Should that be Galaxy's Guide to the Hitchhiker, by Adam Douglas?
      - bru3s 3y ago
        I reckon it's more likely to have come out of World of Disks, by Pratchy Terriett
        raphlinus 3y ago
        To me it recalls "This has made a lot of people very angry and has been widely regarded as a bad move," which is a bit from the introduction and first chapter of the Hitchhiker's Guide.
        gostsamo 3y ago
        Yep, this is the quote.
    - deleted 3y ago
      [deleted]
  - deleted 3y ago
    [deleted]
dataflow 3y ago
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 https://github.com/llvm/llvm-project/issues/64188
selfmodruntime 3y ago
> 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.
jart 3y ago
It sounds like Torvalds has finally found a way to delay the Rust developers taking over the kernel.
SloopJon 3y ago
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.

114 points by jmillikin 3y ago

> 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.

bru3s 3y ago
Very reminiscent of Adam Douglas' writing style (or Terry Pratchett FWIW)
- gostsamo 3y ago
  > This prospect is seen as a bad thing. This is almost word for word lifted from The Hitchhiker's Guide to the Galaxy.
  - zellyn 3y ago
    Should that be Galaxy's Guide to the Hitchhiker, by Adam Douglas?
    - bru3s 3y ago
      I reckon it's more likely to have come out of World of Disks, by Pratchy Terriett
      - raphlinus 3y ago
        To me it recalls "This has made a lot of people very angry and has been widely regarded as a bad move," which is a bit from the introduction and first chapter of the Hitchhiker's Guide.
        gostsamo 3y ago
        Yep, this is the quote.
  - deleted 3y ago
    [deleted]
- deleted 3y ago
  [deleted]

dataflow 3y ago

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 https://github.com/llvm/llvm-project/issues/64188

selfmodruntime 3y ago

> 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.

jart 3y ago

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

SloopJon 3y ago

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.