More Rust concepts for the kernel [LWN.net]

More Rust concepts for the kernel

Posted Sep 20, 2021 23:15 UTC (Mon) by roc (subscriber, #30627)
In reply to: More Rust concepts for the kernel by atnot
Parent article: More Rust concepts for the kernel

Also, if you find yourself with exclusive ownership of a Mutex, you can call into_inner() to take ownership of the contents without taking the lock.

There probably are some weird locking patterns that Rust Mutex can't express but it's not easy to come up plausible ones out of thin air. Probably some conditional stuff where a lock is only needed under certain dynamic conditions. Of course you could probably still write a custom Mutex implementation that encapsulates those conditions in a nice way.

to post comments

More Rust concepts for the kernel

Posted Sep 20, 2021 23:35 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Notably, the API could be something like (purely a sketch):

/// A token which indicates that it is safe to access data 
pub struct SafeToken(());

impl SafeToken {
    pub fn new(proof: SafeTokenProof) -> Self {
        assert!(proof.verify()); // Or run unconditionally.
        Self(())
    }
}

impl<T> KMutex<T> {
    pub fn mut_proven(&self, _: SafeToken) -> &mut T {
        todo!()
    }
}

In reality, something along the lines of GhostCell/GhostToken is probably wanted to tie the given token to a given mutex instance, but it really depends on the situation.

More Rust concepts for the kernel

Posted Sep 21, 2021 9:31 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (2 responses)

The main locking pattern that Mutexes don't model is where a single mutex protects many objects, which sometimes has better performance than extremely fine-grained locking. RCU also requires some custom smart pointers (such as https://github.com/bonzini/rust-rcu-qemu/blob/master/src/...).

More Rust concepts for the kernel

Posted Sep 22, 2021 0:22 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

Normally you'd reorganize your data in that case so that the data protected by the mutex are all under one object. I guess for the kernel you can't always do that.

You may be able to use something similar to qcell to handle it --- https://docs.rs/qcell/0.4.3/qcell/index.html. Basically have a mutex that hands out an exclusively-owned access token, and the access token can be used to "lock" multiple protected data items without actually taking a lock.

More Rust concepts for the kernel

Posted Sep 22, 2021 0:23 UTC (Wed) by roc (subscriber, #30627) [Link]

I see mathstuf already suggested that, oops.