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

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

[Daniel Gomez]

We propose a topic to discuss the potential use of Rust in core Linux
kernel data structures.

The XArray unified the kernel's radix trees into one API back in v4.20
(2018). It sits under the page cache, block layer, filesystems, GPU
drivers, and dozens of other subsystems.

We looked at XArray bugs since 2018. About half are the usual suspects:
races, resource leaks, encoding and overflow mistakes. The kind of bugs
Greg says make up 60-80% of kernel security bugs [1]. Most of the rest
are complex logic bugs where Rust's type system may help but cannot
eliminate entirely.

The motivation for our interest in evaluating Rust for use in the XArray
started with a bug in mm/filemap.c that corrupted page cache data [2].
Consumer code called xa_get_order() without the lock, the tree changed,
and pages from wrong files ended up in the cache. No CVE was assigned
to this issue*, and no reproducer outside production existed before the
fix (a synthetic reproducer was only created [5][6] after the issue was
escalated). Kairui Song's refactoring and optimization patches [7][8][9]
happened to eliminate the issue.

In Rust, xa_get_order() would be a method on the lock guard. XArray
users would not be able to call it without holding the lock because
the type system would not let them. That does not help with the complex
logic bugs, but it eliminates the class of mistakes where the API is
used outside its required context.

We have a Rust XArray prototype that implements core operations designed
around Rust's ownership model. By the conference we aim to benchmark
it against tools/testing/radix-tree/ and use it to back the Rust null
block driver for A/B testing performance against the C implementation.
In the longer term, we plan to deploy the Rust implementation in the
page cache for A/B testing performance of generic workloads. We invite
the community to take a look at the code (when published), which at the
moment is rather simple as it only covers the core operations.

We know that Rust is not magic. The first kernel Rust CVE was a race
in an unsafe block where the safety comment was wrong [10]. However, we
believe that constraining potential memory safety issues to small unsafe
blocks provides a significant advantage over writing in C, where the
entire program text is to be considered one big unsafe block.

With Rust now part of the kernel's core infrastructure [11], we would
like to explore whether Rust is applicable for use in core MM data
structures. We invite the community to this exploration and we would
like to start the discussion. Specifically, we seek insights into:

 - Which workloads set the performance bar?
 - Would a type-safe API reduce consumer bugs, or would they just move
elsewhere?
 - Would rewriting core data structures introduce new, previously
unseen, bugs**?

*Under the Linux kernel CNA's CVE assignment policy, data corruption
issues do not meet the cve.org definition of a vulnerability and are
therefore not eligible for CVE assignment [3][4].

**Our thought: The existing test suite covers years of real edge cases.
A second implementation running against it is not just a rewrite, it is
differential testing.

Link: https://osskorea2025.sched.com/event/296sD/keynote-rust-in-the-linux-kernel-why-greg-kroah-hartman-linux-kernel-maintainer-and-fellow-the-linux-foundation [1]
Link: https://lore.kernel.org/all/A5A976CB-DB57-4513-A700-656580488AB6@flyingcircus.io [2]
Link: https://www.cve.org/ResourcesSupport/Glossary#glossaryVulnerability [3]
Link: http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process [4]
Link: https://lore.kernel.org/all/d4a1cca4-96b8-4692-81f0-81c512f55ccf@meta.com [5]
Link: https://lore.kernel.org/all/5bee194c-9cd3-47e7-919b-9f352441f855@kernel.dk [6]
Link: https://git.kernel.org/torvalds/c/de60fd8ddeda2 [7]
Link: https://git.kernel.org/torvalds/c/a4864671ca0bf [8]
Link: https://git.kernel.org/torvalds/c/6758c1128ceb4 [9]
Link: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh [10]
Link: https://lore.kernel.org/all/20251213000042.23072-1-ojeda@kernel.org [11]

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

[Matthew Wilcox]

On Tue, Feb 17, 2026 at 03:28:45PM +0100, Daniel Gomez wrote:
> We propose a topic to discuss the potential use of Rust in core Linux
> kernel data structures.

This is premature?  We can't move the pagecache or swap over to use Rust
until we can compile Rust for m68k/parisc/alpha/... or we drop those
architectures from the tree.

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

[Tamir Duberstein]

On Tue, Feb 17, 2026 at 9:28 AM Daniel Gomez <da.gomez@kernel.org> wrote:
>
> We propose a topic to discuss the potential use of Rust in core Linux
> kernel data structures.
>
> The XArray unified the kernel's radix trees into one API back in v4.20
> (2018). It sits under the page cache, block layer, filesystems, GPU
> drivers, and dozens of other subsystems.
>
> We looked at XArray bugs since 2018. About half are the usual suspects:
> races, resource leaks, encoding and overflow mistakes. The kind of bugs
> Greg says make up 60-80% of kernel security bugs [1]. Most of the rest
> are complex logic bugs where Rust's type system may help but cannot
> eliminate entirely.
>
> The motivation for our interest in evaluating Rust for use in the XArray
> started with a bug in mm/filemap.c that corrupted page cache data [2].
> Consumer code called xa_get_order() without the lock, the tree changed,
> and pages from wrong files ended up in the cache. No CVE was assigned
> to this issue*, and no reproducer outside production existed before the
> fix (a synthetic reproducer was only created [5][6] after the issue was
> escalated). Kairui Song's refactoring and optimization patches [7][8][9]
> happened to eliminate the issue.
>
> In Rust, xa_get_order() would be a method on the lock guard. XArray
> users would not be able to call it without holding the lock because
> the type system would not let them. That does not help with the complex
> logic bugs, but it eliminates the class of mistakes where the API is
> used outside its required context.

These benefits are compelling, but they materialize when the _caller_
uses Rust (and when Rust abstractions exist, whether native or
wrappers around C). A stronger case for a Rust implementation would be
justified by internal complexity; IIUC that was the motivation behind
Rust Binder.

> We have a Rust XArray prototype that implements core operations designed
> around Rust's ownership model. By the conference we aim to benchmark
> it against tools/testing/radix-tree/ and use it to back the Rust null
> block driver for A/B testing performance against the C implementation.
> In the longer term, we plan to deploy the Rust implementation in the
> page cache for A/B testing performance of generic workloads. We invite
> the community to take a look at the code (when published), which at the
> moment is rather simple as it only covers the core operations.
>
> We know that Rust is not magic. The first kernel Rust CVE was a race
> in an unsafe block where the safety comment was wrong [10]. However, we
> believe that constraining potential memory safety issues to small unsafe
> blocks provides a significant advantage over writing in C, where the
> entire program text is to be considered one big unsafe block.
>
> With Rust now part of the kernel's core infrastructure [11], we would
> like to explore whether Rust is applicable for use in core MM data
> structures. We invite the community to this exploration and we would
> like to start the discussion. Specifically, we seek insights into:
>
>  - Which workloads set the performance bar?
>  - Would a type-safe API reduce consumer bugs, or would they just move
> elsewhere?
>  - Would rewriting core data structures introduce new, previously
> unseen, bugs**?
>
> *Under the Linux kernel CNA's CVE assignment policy, data corruption
> issues do not meet the cve.org definition of a vulnerability and are
> therefore not eligible for CVE assignment [3][4].
>
> **Our thought: The existing test suite covers years of real edge cases.
> A second implementation running against it is not just a rewrite, it is
> differential testing.

The downside to a second implementation is that it acts as a change
detector: If the tests run against both implementations (and we can't
drop the C implementation since Rust is not yet required to build the
kernel), any change to the C implementation must be accompanied by a
change to the Rust implementation. I'd be surprised if the C folks
would be pleased by this.

>
> Link: https://osskorea2025.sched.com/event/296sD/keynote-rust-in-the-linux-kernel-why-greg-kroah-hartman-linux-kernel-maintainer-and-fellow-the-linux-foundation [1]
> Link: https://lore.kernel.org/all/A5A976CB-DB57-4513-A700-656580488AB6@flyingcircus.io [2]
> Link: https://www.cve.org/ResourcesSupport/Glossary#glossaryVulnerability [3]
> Link: http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process [4]
> Link: https://lore.kernel.org/all/d4a1cca4-96b8-4692-81f0-81c512f55ccf@meta.com [5]
> Link: https://lore.kernel.org/all/5bee194c-9cd3-47e7-919b-9f352441f855@kernel.dk [6]
> Link: https://git.kernel.org/torvalds/c/de60fd8ddeda2 [7]
> Link: https://git.kernel.org/torvalds/c/a4864671ca0bf [8]
> Link: https://git.kernel.org/torvalds/c/6758c1128ceb4 [9]
> Link: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh [10]
> Link: https://lore.kernel.org/all/20251213000042.23072-1-ojeda@kernel.org [11]

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

[Andreas Hindborg]

"Matthew Wilcox" <willy@infradead.org> writes:

> On Tue, Feb 17, 2026 at 03:28:45PM +0100, Daniel Gomez wrote:
>> We propose a topic to discuss the potential use of Rust in core Linux
>> kernel data structures.
>
> This is premature?  We can't move the pagecache or swap over to use Rust
> until we can compile Rust for m68k/parisc/alpha/... or we drop those
> architectures from the tree.

I disagree that this is premature. And I don't think Daniel is
suggesting we swap anything over at this time. Doing this work is not
the same as swapping anything over.

We don't have to wait 5-10 years for gcc to fully support Rust, before
we start playing with this. 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. I think this would benefit everyone. Let's get in
early and help shape the language, rather than board in 10 years when
everything is settled and much more difficult to change.

On the other hand, we might also find that no, Rust does not work for
this. This would be a valuable outcome as well.

At any rate, this is not a call to end support for all architectures
that do not support Rust. Rather, this is a call to figure out if we
should work harder on getting Rust support for m68k et al.

Without doing this exploration, we cannot answer the questions.

Best regards,
Andreas Hindborg

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

[Andreas Hindborg]

"Tamir Duberstein" <tamird@gmail.com> writes:

> On Tue, Feb 17, 2026 at 9:28 AM Daniel Gomez <da.gomez@kernel.org> wrote:
>>
>> We propose a topic to discuss the potential use of Rust in core Linux
>> kernel data structures.
>>
>> The XArray unified the kernel's radix trees into one API back in v4.20
>> (2018). It sits under the page cache, block layer, filesystems, GPU
>> drivers, and dozens of other subsystems.
>>
>> We looked at XArray bugs since 2018. About half are the usual suspects:
>> races, resource leaks, encoding and overflow mistakes. The kind of bugs
>> Greg says make up 60-80% of kernel security bugs [1]. Most of the rest
>> are complex logic bugs where Rust's type system may help but cannot
>> eliminate entirely.
>>
>> The motivation for our interest in evaluating Rust for use in the XArray
>> started with a bug in mm/filemap.c that corrupted page cache data [2].
>> Consumer code called xa_get_order() without the lock, the tree changed,
>> and pages from wrong files ended up in the cache. No CVE was assigned
>> to this issue*, and no reproducer outside production existed before the
>> fix (a synthetic reproducer was only created [5][6] after the issue was
>> escalated). Kairui Song's refactoring and optimization patches [7][8][9]
>> happened to eliminate the issue.
>>
>> In Rust, xa_get_order() would be a method on the lock guard. XArray
>> users would not be able to call it without holding the lock because
>> the type system would not let them. That does not help with the complex
>> logic bugs, but it eliminates the class of mistakes where the API is
>> used outside its required context.
>
> These benefits are compelling, but they materialize when the _caller_
> uses Rust (and when Rust abstractions exist, whether native or
> wrappers around C). A stronger case for a Rust implementation would be
> justified by internal complexity; IIUC that was the motivation behind
> Rust Binder.

I agree with all of this. Having spent a fair amount of time reading the
xarray code, I am very interested in seeing how a feature complete
implementation of xarray would look like in Rust, and how it would read.

For C callers we could do things similar to what our current C data
structures already do. Asserting preconditions for calling certain
functions, lock held, etc. I am curious how much of this we could do
automatically with Rust.

>
>> We have a Rust XArray prototype that implements core operations designed
>> around Rust's ownership model. By the conference we aim to benchmark
>> it against tools/testing/radix-tree/ and use it to back the Rust null
>> block driver for A/B testing performance against the C implementation.
>> In the longer term, we plan to deploy the Rust implementation in the
>> page cache for A/B testing performance of generic workloads. We invite
>> the community to take a look at the code (when published), which at the
>> moment is rather simple as it only covers the core operations.
>>
>> We know that Rust is not magic. The first kernel Rust CVE was a race
>> in an unsafe block where the safety comment was wrong [10]. However, we
>> believe that constraining potential memory safety issues to small unsafe
>> blocks provides a significant advantage over writing in C, where the
>> entire program text is to be considered one big unsafe block.
>>
>> With Rust now part of the kernel's core infrastructure [11], we would
>> like to explore whether Rust is applicable for use in core MM data
>> structures. We invite the community to this exploration and we would
>> like to start the discussion. Specifically, we seek insights into:
>>
>>  - Which workloads set the performance bar?
>>  - Would a type-safe API reduce consumer bugs, or would they just move
>> elsewhere?
>>  - Would rewriting core data structures introduce new, previously
>> unseen, bugs**?
>>
>> *Under the Linux kernel CNA's CVE assignment policy, data corruption
>> issues do not meet the cve.org definition of a vulnerability and are
>> therefore not eligible for CVE assignment [3][4].
>>
>> **Our thought: The existing test suite covers years of real edge cases.
>> A second implementation running against it is not just a rewrite, it is
>> differential testing.
>
> The downside to a second implementation is that it acts as a change
> detector: If the tests run against both implementations (and we can't
> drop the C implementation since Rust is not yet required to build the
> kernel), any change to the C implementation must be accompanied by a
> change to the Rust implementation. I'd be surprised if the C folks
> would be pleased by this.

I don't think anyone suggests putting this Rust code into production
first thing (if ever). Current C development should not be impacted,
they should continue as they please.

It would be a cat and mouse situation the people working on the Rust
code for sure. But maybe that is OK.


Best regards,
Andreas Hindborg

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

[Miguel Ojeda]

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! :)

Technically, adding Rust "core" code can be done today, whether for
Rust callers only (which as Tamir says is where a lot of advantages
really show) or for C callers too (where a "native Rust"
implementation can be simpler than dealing with "abstractions" of C
APIs).

So it is all a matter of maintainers being OK with the costs. To me,
this is similar to the "Rust reference drivers" proposal, but for
currently non-configurable parts of the kernel:

    https://rust-for-linux.com/rust-reference-drivers

Cheers,
Miguel

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

[Miguel Ojeda]

On Tue, Feb 17, 2026 at 6:51 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> We don't have to wait 5-10 years for gcc to fully support Rust, before
> we start playing with this.

By the way, I don't think we will need that many years to use GCC if
companies are interested on it and support projects like GCC Rust
and/or `rustc_codegen_gcc`, given their current state (for context,
the latter is able to boot a kernel with Rust enabled for x86_64, and
the former is prioritizing Rust for Linux).

Let me use this opportunity to say: if anyone wants to support that
work, e.g. hardware companies for their architecture, then please ping
me and I am happy to help getting in touch with them and figuring
funding and things like that.

Cheers,
Miguel

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

[Andreas Hindborg]

"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

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

[Daniel Gomez]

On 2026-02-17 21:18, Miguel Ojeda wrote:
> On Tue, Feb 17, 2026 at 6:51 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
> >
> > We don't have to wait 5-10 years for gcc to fully support Rust, before
> > we start playing with this.
> 
> By the way, I don't think we will need that many years to use GCC if
> companies are interested on it and support projects like GCC Rust
> and/or `rustc_codegen_gcc`, given their current state (for context,
> the latter is able to boot a kernel with Rust enabled for x86_64, and
> the former is prioritizing Rust for Linux).
> 
> Let me use this opportunity to say: if anyone wants to support that
> work, e.g. hardware companies for their architecture, then please ping
> me and I am happy to help getting in touch with them and figuring
> funding and things like that.

I'm not aware of the official GCC roadmap but LWN covered it in
"predictions for the new year" article [1]. Quoting:

"The gccrs project will deliver a working Rust compiler this year; it
will be usable to build the kernel's Rust code. This ambitious project
...
The availability of a GCC-based compiler will make that transition
easier for many people, especially those working with architectures that
the LLVM-based rustc compiler does not support..."

Link: https://lwn.net/Articles/1052269/ [1]

Whether that becomes true or not should not be relevant for the
discussion, as stated in this thread.