Rust in the Linux kernel (Google security blog)

Posted Apr 15, 2021 22:24 UTC (Thu) by ofranja (guest, #11084)
In reply to: Rust in the Linux kernel (Google security blog) by mkubecek
Parent article: Rust in the Linux kernel (Google security blog)

> In such code, the naive approach of "just lock everything that can be accessed concurrently" does not scale any more so that various lockless implementations tend to replace simple locking.

Why do you think you are forced to use any naïve approach?

There are a number of crates that provide lockless/lockfree implementations of data structures and synchronization algorithms.

Rust in the Linux kernel (Google security blog)

Posted Apr 15, 2021 23:21 UTC (Thu) by mkubecek (guest, #130791) [Link] (4 responses)

> Why do you think you are forced to use any naïve approach?
>
> There are a number of crates that provide lockless/lockfree implementations of data structures and synchronization algorithms.

The blogpost says so, I quoted that part in my comment.

Rust in the Linux kernel (Google security blog)

Posted Apr 15, 2021 23:24 UTC (Thu) by ofranja (guest, #11084) [Link]

This is talking about safe Rust only.

Rust in the Linux kernel (Google security blog)

Posted Apr 15, 2021 23:59 UTC (Thu) by wedsonaf (guest, #151305) [Link] (2 responses)

> The blogpost says so, I quoted that part in my comment.

You are, perhaps unintentionally, misrepresenting what I say in the blogpost.

If you read carefully, you'll see that when I talk about interior mutability I give mutexes and spinlocks as examples, but I also mention atomics. If your data can be encapsulated in something that fits in an atomic variable, it is safe and as fast as C. If it can't, then you're still welcome to use atomics and unsafe blocks to implement your lock-free thing. The expectation is that you'll build a safe zero-cost abstraction and restrict the unsafe part to a small section that will be scrutinised, but users of your code will themselves be free of unsafe code. The result will be as fast as C as well. Nothing is forcing you to use mutexes and spinlocks -- in fact, they are examples of such implementations that use unsafe blocks but expose a safe interface to callers.

There are, of course, cases when extra safety does come at a runtime cost (e.g., when Rust needs to refcount to ensure safety, where C might rely on potentially-unsound or not-quite-future-proof invariants to avoid refcounting).

Rust in the Linux kernel (Google security blog)

Posted Apr 16, 2021 7:06 UTC (Fri) by mkubecek (guest, #130791) [Link] (1 responses)

> If your data can be encapsulated in something that fits in an atomic variable, it is safe and as fast as C. If it can't, then you're still welcome to use atomics and unsafe blocks to implement your lock-free thing.

That's the easy case. But it's not nearly always the case.

> The expectation is that you'll build a safe zero-cost abstraction and restrict the unsafe part to a small section that will be scrutinised, but users of your code will themselves be free of unsafe code.

If it can work like that, it's fine and it likely already works like that even without rust. But it does not nearly always work like that. If it did, you wouldn't find so many occurences of READ_ONCE(), WRITE_ONCE() or explicit memory barriers through the code and we could have them hidden inside those opaque abstractions.

For example, some of the READ_ONCE() and WRITE_ONCE() were added for values set via sysctl or socket options (e.g. various limits or default values) where we don't really care if there is an inconsistency between threads picking the old or new value but as they are used in fast path, we do care about the overhead of having the access really safe. But again, this is just one example which you could probably build some abstraction around; but there are more complicated uses, e.g. just yesterday I stumbled upon the barrier in net_tx_action() and comment explaining why it's needed. And this is still one of the simpler cases. I doubt you can build zero cost abstractions around all of them.

Rust in the Linux kernel (Google security blog)

Posted Apr 16, 2021 7:33 UTC (Fri) by matthias (subscriber, #94967) [Link]

I think READ_ONCE() and WRITE_ONCE() are quite good examples. In a way they already are abstractions. The problem with C is, that there is no easy way of enforcing the usage. With rust, you would wrap data that should be accessed by these macros in a new data type (with zero runtime cost). And the only reason for this type to be there would be to enforce the usage of READ_ONCE() and WRITE_ONCE(). The compiler would just throw an error if you try to access the data by other means (unless you explicitly use unsafe of course).

I do not know the kernel well enough to talk about every feature whether it can be abstracted with zero cost. But it is always possible to use unsafe at the very position where optimization is crucial and document why unsafe is used there and why the code is still safe. Yeah, you would not have a safe abstraction there, but you still would have the unsafe tag expressing that you have to be very careful at this particular place. If you use unsafe, then you can do the very same things that are possible in C.