linux-kernel - Re: [PATCH 4/4] build: rust: provide an option to inline C helpers into 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: <aTGJdlwMRxGg2iZ1@google.com>
Date: Thu, 4 Dec 2025 13:15:34 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: "Emilio Cobos Álvarez" <emilio@...sal.io>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Peter Zijlstra <peterz@...radead.org>, 
	Antoni Boucher <bouanto@...o.com>, Arthur Cohen <arthur.cohen@...ecosm.com>, 
	Gary Guo <gary@...yguo.net>, Josh Triplett <josh@...htriplett.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, 
	"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Alexandre Courbot <acourbot@...dia.com>, Will Deacon <will@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev, linux-kbuild@...r.kernel.org, linux-mm@...ck.org, 
	nouveau@...ts.freedesktop.org, Matthew Maurer <mmaurer@...gle.com>
Subject: Re: [PATCH 4/4] build: rust: provide an option to inline C helpers
 into Rust

On Thu, Dec 04, 2025 at 01:49:28PM +0100, Emilio Cobos Álvarez wrote:
> On 12/4/25 12:57 PM, Miguel Ojeda wrote:
> > On Thu, Dec 4, 2025 at 12:11 PM Peter Zijlstra <peterz@...radead.org> wrote:
> > > 
> > > Right. Earlier I also proposed using libclang to parse the C header and
> > > inject that. This might be a little simpler, in that..
> > 
> > Yeah, that would be closer to the `bindgen` route in that `libclang`
> > gets already involved.
> 
> Yeah, so... there are existing tools (c2rust [0] being the actively
> maintained one IIUC) that in theory could do something like that (translate
> the bodies of the functions from C to Rust so that rustc could consume them
> directly rather than via LLVM LTO).
> 
> I think the intended use case is more "translate a whole C project into
> rust", but it could be interesting to test how well / poorly it performs
> with the kernel helpers / with a single header translated to Rust.
> 
> I personally haven't tried it because for work I need to deal with C++,
> which means that automatic translation to Rust is a lot harder / probably
> impossible in general. So for Firefox we end up relying on bindgen +
> cross-language LTO for this kind of thing, and it works well for us.
> 
> If I'm understanding correctly, it seems the kernel needs this extra bit of
> help (__always_inline) to push LLVM to inline C functions into rust, which
> is a bit unfortunate... But this approach seems sensible to me, for now at
> least.
> 
> FWIW Bindgen recently gained an option to generate inline functions [1],
> which could help avoid at least the bindgen ifdef in the patch series?
> 
> Anyways, it might be interesting to give c2rust a go on the kernel helpers
> if nobody has done so, and see how well / poorly it works in practice? Of
> course probably introducing a new dependency would be kind of a pain, but
> could be a good data point for pushing into adding something like it built
> into rustc...

I already tried c2rust as an alternative to this patch. It works okay
for many functions, but it's missing support for some features such as
asm goto, though this is fixable. But a larger issue is that some things
simply do not translate to Rust right now. For example:

* Atomics use the Ir operand.
* static_branch uses the i operand.

neither of which translate directly to Rust.

Alice