Conversation

Thinking about Rust in the kernel again, does Rust have some kind of generic version of the idea of unsafe/safe code, as an attribute? Often in kernel land you're allowed to call functions only in certain contexts (process, atomic, etc.) and locking has to follow an order.

171

Replying to

It can be represented this in the type system with ownership similar to managing resources, lock scopes, etc. Those functions can require a reference to the type of object representing the required state and then it's not possible to call them outside of the lifetime of it.

Replying to

That's not practical because it would mean *every* function has to take such a reference, since the default is "may sleep". The problem isn't functions requiring a special context, it's functions forbidding *all but* a special context.

Replying to

It's not able to represent the inverse of that. If there's any way to use a function in a type or memory unsafe way it has to be marked unsafe. Safe code doesn't have non-atomic data races, etc. Most of this is already covered by safe vs. unsafe. You have to make safe primitives.

Replying to

and

It's incorrect to use unsafe blocks to make safe functions where there's a way to use them in a way that causes undefined behavior, including via concurrency. Locking has to be properly turned into safe primitives. It has to be done that way or it can't be non-unsafe Rust code.

8:16 AM · May 16, 2022Twitter Web App

Likes

Who can reply?

People @marcan42 follows or mentioned can reply

Replying to

You're confused about what I want. This isn't about memory safety. It's about execution state. You can't call nonatomic functions from atomic context not because they'll corrupt memory, but because they may deadlock.

Replying to

and

For example, safe code will often use mutexes to control access to shared resources, and you are not allowed to lock mutexes in atomic context since that operation may sleep. Obviously we can't mark every function that locks a mutex unsafe. It's a different concept.

Show replies

Replying to

and

Any API requirement where not following it leads to any kind of undefined behavior (type / memory unsafety) is mandatory to enforce for safe code. There's just safe or unsafe without unsafe broken up into subsets. Unsafe code is responsible for not leaking unsafety to safe code.