linux-kernel - Re: [PATCH v14 00/16] Refcounted interrupts, SpinLockIrq for rust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4b6ae41e-5cda-41ab-ba4e-628bdf23f917@nvidia.com>
Date: Thu, 20 Nov 2025 15:16:04 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Lyude Paul <lyude@...hat.com>, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Cc: Boqun Feng <boqun.feng@...il.com>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v14 00/16] Refcounted interrupts, SpinLockIrq for rust

On 11/20/25 1:45 PM, Lyude Paul wrote:
...
>   this new interface is indeed possible, more on this below.
> * Also thank to Joel, we also now have actual benchmarks for how this
>   affects performance:
>   https://lore.kernel.org/rust-for-linux/20250619175335.2905836-1-joelagnelf@nvidia.com/
> * Also some small changes to the kunit test I added, mainly just making
>   sure I don't forget to include a MODULE_DESCRIPTION or MODULE_LICENSE.

Hi,

The above link says that local_interrupt takes 3.6x as as as local_irq.

This is alarming, but is it the final word? In other words, is the Rust
side of this doomed to slower performance forever, or is there some
hope of reaching performance parity with the C part of the kernel?

Do we have to start telling the Rust for Linux story this way: "our
new Rust-based drivers are slower, but memory-safer"?

I'm not able to deduce the answer from a quick scan through the patches
and the cover letter.

thanks,
-- 
John Hubbard