Re: [LSF/MM/BPF TOPIC] Evaluating Rust for XArray

[Andreas Hindborg <a.hindborg@kernel.org>]

"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com> writes:

> On Tue, Feb 17, 2026 at 6:51 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> We can, and should, start evaluating if we
>> can deploy Rust in this area now. We might find that we are lacking
>> something from the Rust language to do what we want. We can work with
>> the Rust developers to make sure that the Rust language gets all the
>> bells and whistles that it needs, to support the use cases we have for
>> the Linux kernel.
>
> To clarify for others that may not have the context...
>
> We are already working with upstream Rust (and have been for years
> now) on improving the Rust language for the Linux kernel. We have
> regular meetings with them every two weeks, and have a shared roadmap.
>
> To give a sense of the collaboration status, some major language
> features are getting developed with/for/by the Linux kernel and the
> kernel is even built in their pre-merge CI.
>
> In terms of discovering features needed, I don't think there will be
> big surprises there, given all the work done so far. But if the plan
> is to expose a C API, then we may actually find we want new things
> from the C language instead! :)

I can lead with an example of what I mean.

The C xarray uses a few different node types internally. Pointers to
these nodes encode information about how to decode the pointee, in the
lower two bits of the pointer. This is possible because of alignment
guarantees of the pointee. It's a neat trick, basically implementing the
pointer as a tagged union, without requiring extra memory for the tag.

In Rust, enums are tagged unions implemented by the compiler. This is
necessary to provide memory safety and avoid type confusion bugs. The
compiler will usually implement the discriminant as an extra word.
Sometimes it is able to optimize the encoding of the discriminant to
avoid this extra word. This is the case for the `Option<NonNull<_>>`
type for instance. The compiler knows that `NonNull` never uses the bit
pattern of all zeroes, and it assigns that bit pattern to be the `None`
variant of the `Option<_>` type. All bit patterns that are not all zero
will be the `Some(NonNull)` variant.

But the rust compiler is not currently able to utilize knowledge about
alignment to encode tagged union discriminant in the lower order bits of
a pointer. So when we implement xarray internal node pointers in Rust
today, we do so the same way the C code does it; by manipulating a
pointer value and injecting metadata into the lower order bits. This is
of course an unsafe operation, because dereferencing a pointer that has
been manipulated in this way can lead to loads or stores to arbitrary
places, if done wrong.

We talked to our contact points with upstream Rust about this, and they
believe the compiler and language could be made able to do this in a
safe way.

We will try to push for this optimization to be available in the
compiler, because it gives everyone a safe way to access this trick. And
it would allow us to cut a big chunk of unsafe code from our Rust XArray
implementation. Memory safety is one of the reasons for looking into
this work, after all.

Not having this optimization does not mean that Rust is not ready. But
if we can get it, it would be great.

I can't tell if we will run into more situations like this one when we
try to apply Rust in various places in the kernel. And this is one of
the reasons that we should do this work.


Best regards,
Andreas Hindborg