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

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

"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