Rust's Mutex type (obviously not suitable for the kernel, but this reflects the approach you'd use) has a lock() method and that's how you get the thing protected by the Mutex. let mut foo = foo_lock.lock().unwrap(); gives you foo, the thing locked by foo_lock, if you meant to lock bar instead of foo, well, you've got foo here, there is no bar variable, to get that you need to let bar = bar_lock.lock().unwrap() instead or as well.

[ If you wonder, how do I *unlock* the Mutex then, the answer is you just get rid of the locked data the lock is protecting, this would happen as soon as the variable foo goes out of scope of course but if for any reason that's not soon enough, just call drop(foo) and since foo was moved into the empty function it's gone and the unlock happens immediately, if you feel the need for a more self-documenting way to write this, Nightly Rust provides unlock() which takes your data foo and drops it for you ]

Obviously Rust type magic can't cure pure logic errors. If the problem was that the code locks and modifies some totally unrelated tty, that might still be a grave Linux bug, but this type of bug where the wrong thing was locked but the right thing was modified (or vice versa) is avoided in Rust.

Posted Oct 20, 2021 22:24 UTC (Wed) by roc (subscriber, #30627) [Link]

We can either continue to engage in this kind of unproductive finger wagging and continue to see a steady stream of security issues or figure out a better way to handle the development that allows imperfect developers and reviewers (which happens to be almost all of them) to work with core infrastructure code in a more secure fashion.

Who never made a mistake, made nothing.

Otherwise ... if you only hire people who never make mistakes like this, you would never hire anyone, not even yourself.