Re: [TECH TOPIC] Rust for Linux

[Wedson Almeida Filho <wedsonaf@google.com>]

On Thu, Jul 08, 2021 at 08:11:10AM +0200, Greg KH wrote:
> Thanks for the detailed explainations, it seems rust can "get away" with
> some things with regards to reference counts that the kernel can not.
> Userspace has it easy, but note that now that rust is not in userspace,
> dealing with multiple cpus/threads is going to be interesting for the
> language.
>
> So, along those lines, how are you going to tie rust's reference count
> logic in with the kernel's reference count logic?  How are you going to
> handle dentries, inodes, kobjects, devices and the like?  That's the
> real question that I don't seem to see anyone even starting to answer
> just yet.

None of what I described before is specific to userspace, but I understand your
need to see something more concrete.

I'll describe what we've done for `task_struct` and how lifetimes, aliasing
rules, sync & send traits help us achieve zero cost (when compared to C) but
also gives us safety. The intention here is to show that similar things can (and
will) be done to other kernel reference-counted objects when we get to them.

So we begin with `current`. It gives us access to the current task without
incurring any increments or decrements of the refcount; in Rust, we'd do the
following:

  let current = Task::current();

We can use it for however long we'd like as long as it's in the same task. But
how do we restrict that? Rust has this `Send` trait that tells it that a type
can be used by another thread/CPU; `current`'s type doesn't isn't `Send`, so
attempting to send it another thread fails. For example, if we tried this:

  send_to_thread(current);

We'd get the following compiler error:

    |
195 | fn send_to_thread<T: Send>(t: T) {
    |                      ---- required by this bound in `send_to_thread`
...
201 |     send_to_thread(current);
    |     ^^^^^^^^^^^^^^ `*mut ()` cannot be sent between threads safely
    |
    = help: within `TaskRef<'_>`, the trait `Send` is not implemented for `*mut ()`
    = note: required because it appears within the type `(&(), *mut ())`
    = note: required because it appears within the type `PhantomData<(&(), *mut ())>`
note: required because it appears within the type `TaskRef<'_>`

One option we do have is to send a "reference" to `current` to another thread.
This works and is zero-cost. It is safe because the lifetime of the reference is
tied to that of `current`. (And `current`'s type is `Sync`, which means that a
reference to it is safely shareable with another thread/CPU.)

So calling:

  send_to_thread(&current);

Works fine. But its implementation must convince the compiler that by the time
it returns the sharing with another thread is over. Otherwise it would be a
violation of lifetime requirements (a borrow cannot outlive the borrowed value)
and compilation would fail.

Now, similarly to my example in another email, if you really want the task to
outlive `current`, then you can call `clone`. This results in `get_task_struct`
being called, so now we can send it another thread that can hold on to it and
this is all safe. For example:

    let current = Task::current();
    let task = current.clone();
    send_to_thread(task);

Now, the other task *owns* the reference, so we're not supposed to use `task` at
all (suppose for a moment that it's some arbitrary task, not current). In C,
given that there is no ownership discipline enforced by the compiler, one could
easily make the mistake of using `task` (which is unsafe because the other
thread/CPU may have decremented its refcount and freed it by now). In Rust, an
attempt to use `task` would fail; for example:

    let current = Task::current();
    let task = Task::current().clone();
    send_to_thread(task);
    pr_info!("Pid is {}", task.pid());

Would result in the following compilation error:

error[E0382]: borrow of moved value: `task`
   --> rust/kernel/task.rs:203:34
    |
201 |     let task = Task::current().clone();
    |         ---- move occurs because `task` has type `Task`, which does not implement the `Copy` trait
202 |     send_to_thread(task);
    |                    ---- value moved here
203 |     pr_info!("Pid is {}", task.pid());
    |                           ^^^^ value borrowed here after move

(Note that `task` is inaccessible despite still being in scope.)

Another common mistake is to leak references by forgetting to call
`put_task_struct`. Rust helps prevent this by automatically calling it when
needed, including error paths. Suppose we have a function that allocates some
struct that includes a task field, for example:

struct X {
    task: Task,
    a: u64,
    b: u64,
}

fn alloc_X(task: Task) -> Result<Box<X>> {
    Box::try_new(X {
        task: task,
        a: 10,
        b: 20
    })
}

Here, if the function fails (e.g., the allocation in `try_new` fails), the task
refcount is automatically decremented when the function returns. If it succeeds,
ownership is transferred to the new instance of X, and the refcount will be
decremented automatically when this instance of X is eventually freed.

Another example that shows lifetimes clearly is that of `group_leader`. Given a
task, its group leader can be accessed with zero-cost but this access is
subjected to lifetime requirements. For example:

    let task = get_some_task();
    let leader = task.group_leader();
    pr_info!("Pid is {}", leader.pid());

Works with zero cost (i.e., no extra inc/ref of the group leader). But the
following:

    let leader;
    {
        let task = get_some_task();
        leader = task.group_leader();
    }
    pr_info!("Pid is {}", leader.pid());

Fails with the following error:

error[E0597]: `task` does not live long enough
   --> rust/kernel/task.rs:209:18
    |
209 |         leader = task.group_leader();
    |                  ^^^^ borrowed value does not live long enough
210 |     }
    |     - `task` dropped here while still borrowed
211 |     pr_info!("Pid is {}", leader.pid());
    |                           ------ borrow later used here

Because task's refcount is decremented at the end of the scope.

So, you see, I understand that you want to see refcounts in action on the
objects you care about. But I don't think the claim that no one has even tried
to answer the general refcount question is accurate. I hope it is clear that we
have thought about some of this. You could also check out what we've done for
file references and even file-descriptor creation with transaction semantics for
how it all fits beautifully (and safely). (I won't get into them here because
this email is already too long.)

I'm happy to go into more details for any of the examples above if anything
isn't clear.

> And that's the reason some of us are asking to see a "real" driver, as
> those have to deal with these kernel-controlled-reference-counted
> objects properly (as well as hardware control).  Seeing how that is
> going to work in this language is going to be the real sign of if this
> is even going to be possible or not.

Here's what I'd like to avoid: spending time on something that you all still
think is not typical enough. Would you be able to point us to a driver that
would showcase the interactions you'd like to see so that (once we have it in
Rust) we can have a discussion about the merits of the language?

Hopefully something with interesting interactions with the kernel, but not
with overly complex hardware, that is, something that doesn't require us to read
a 400-page specification to implement.

Thanks,
-Wedson