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] [thread-next>] [day] [month] [year] [list]

Message-ID: <49d7b2c0-9794-4997-8bba-78891f27abf0@nvidia.com>
Date: Fri, 21 Nov 2025 17:09:24 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Lyude Paul <lyude@...hat.com>, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 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/21/25 9:47 AM, Boqun Feng wrote:
> On Thu, Nov 20, 2025 at 03:16:04PM -0800, John Hubbard wrote:
>> On 11/20/25 1:45 PM, Lyude Paul wrote:
>> ...
>> 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?
>>
> 
> Note that local_interrupt API is for safe Rust code, you can always
> use unsafe local_irq if the interrupt disabling is the performance
> bottleneck for you. So language-wise there is no difference between Rust
> and C.
>

OK, but there *is* a performance difference between Safe Rust (which is
the whole point of this project, after all) and C.

Is 3.6x longer really something we are stuck with? Or is there some other
way forward that could potentially provide higher performance, for Safe
Rust?

 
>> Do we have to start telling the Rust for Linux story this way: "our
>> new Rust-based drivers are slower, but memory-safer"?
>>
> 
> I would not jump into that conclusion at the moment, because 1) as I
> mentioned you can always go into unsafe if something begins the
> bottleneck, and 2) there is always a gap between micro benchmark results
> and the whole system performance, being slow on one operation doesn't
> means the whole system will perform observably worse.
> 
> Think about a similar thing in C, we recommend people to use existing
> locks instead of customized synchronization vi atomics in most cases,
> and technically, locks can be slower compared to a special
> synchronization based on atomics, but it's more difficult to mess up.
> 

Yes yes, I fully understand that micro benchmarks don't always translate
to a real-world observable effects. But interrupt operations...those can
be on a hot path. So it's prudent to worry about these.


thanks,
-- 
John Hubbard