To be clear: I like Rust. It's great, I use it a lot. But, Rust's memory safety stuff can't really save you from the screwiness of ISRs. Here's a long-winded example:
ST has a nifty double-buffer DMA mode for their ADCs, so you can give the ADC two different buffers, it'll fill one, fire an IRQ, you catch the IRQ and handle the data, meanwhile, it's filling the other buffer, and the IRQ fires again, you handle the data in the other buffer, rinse, repeat.
This allows the ADC to run continuously, monotonically and at very high sample rates, without monopolizing CPU. It's really a terrific design. I used it for a DIY telephony project once to run continuous FFTs on several ADC channels at once.
This is all fun, but the architecture introduces synchronization issues that aren't immediately solvable within Rust's data model.
Okay, so I can't run the FFT from within the ISR, so I delegate that to a thread. Do I have the thread read the DMA buffer directly, and just pray that it does it fast enough that the ADC doesn't loop back around to that buffer until the thread is done?
Or, do I have the ISR copy the buffer into a queue, mitigating the memory corruption risk? Well that seems good, but how do I make the queue visible to both the ISR and the thread? The ISR takes no arguments, it's just an address the CPU jumps to when a thing happens. Thus, the queue has to be global, which means more unsafe blocks and more very un-idiomatic Rust.
side note: in my use case, it actually worked just fine with the thread reading straight from the DMA buffer, even with the risk of memory corruption. But you can imagine use cases where the risk would be more severe, like maybe decoding packets from a serial interface.
So I would say that any easy answer like “this would not compile” would just be a guess, because you would want to know more of the particulars in order to answer this question.
I know that this is kind of a non-answer, but if you want to write a kernel in Rust you have to figure out boundaries for where unsafe {} are. In a kernel, there are probably large chunks of unsafe {} and the Rust compiler prevents certain bugs outside unsafe {} assuming there aren’t bugs inside unsafe {} that would prevent the type checker from doing its job correctly.
1. Slap a reference count on it.
2. Use `unsafe` to promise the compiler that your code is right.
I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.
Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
Yes Rust is one language that can be widely deployed in systems programming and potentially avoid classes of memory and ownership errors. No it doesn’t magically solve all the problems. Saying “Rust would fix this” in a hypothetical situation where Rust existed in 1995 or OpenBSD was rewritten from scratch, ok, well maybe. As of today only research kernels and a very small fraction of Linux systems have been written in Rust when we are talking about kernels.
People without systems and embedded programming experience need to sit down.
I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” which means you’ll be pinky-swearing to the compiler.
And for my cursory glances at the code, most structures are handled well, that it’s mostly logic bug (from bad data) instead of bad memory access (which can happen).
Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.