Message-ID: <aS-WlwsvGrbGYIYs@tardis.local>
Date: Tue, 2 Dec 2025 17:47:03 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Ertman <david.m.ertman@...el.com>,	Ira Weiny <ira.weiny@...el.com>,
 Leon Romanovsky <leon@...nel.org>,	Peter Zijlstra <peterz@...radead.org>,
	Elle Rhumsaa <elle@...thered-steel.dev>,
	Carlos Llamas <cmllamas@...gle.com>,	Yury Norov <yury.norov@...il.com>,
	Andreas Hindborg <a.hindborg@...nel.org>,	linux-block@...r.kernel.org,
	FUJITA Tomonori <fujita.tomonori@...il.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, linux-clk@...r.kernel.org,
	Benno Lossin <lossin@...nel.org>,	Danilo Krummrich <dakr@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>, linux-pm@...r.kernel.org,
	Paul Moore <paul@...l-moore.com>, Serge Hallyn <sergeh@...nel.org>,
	linux-security-module@...r.kernel.org,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Abdiel Janulgue <abdiel.janulgue@...il.com>,
	Robin Murphy <robin.murphy@....com>, Lyude Paul <lyude@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	linux-fsdevel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
	Jason Baron <jbaron@...mai.com>,	Steven Rostedt <rostedt@...dmis.org>,
	Ard Biesheuvel <ardb@...nel.org>,
	Brendan Higgins <brendan.higgins@...ux.dev>,
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>,
	linux-kselftest@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Andrew Ballance <andrewjballance@...il.com>,
	maple-tree@...ts.infradead.org, linux-mm@...ck.org,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Uladzislau Rezki <urezki@...il.com>,
	Vitaly Wool <vitaly.wool@...sulko.se>,	Rob Herring <robh@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Krzysztof Wilczy´nski <kwilczynski@...nel.org>,
	linux-pci@...r.kernel.org, Remo Senekowitsch <remo@...nzli.dev>,
	"Paul E. McKenney" <paulmck@...nel.org>, rcu@...r.kernel.org,
	Will Deacon <will@...nel.org>, Fiona Behrens <me@...enk.dev>,
	Gary Guo <gary@...yguo.net>, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,	Alexandre Courbot <acourbot@...dia.com>,
	Vlastimil Babka <vbabka@...e.cz>, Christoph Lameter <cl@...two.org>,
	David Rientjes <rientjes@...gle.com>,	Ingo Molnar <mingo@...hat.com>,
 Waiman Long <longman@...hat.com>,
	Mitchell Levy <levymitchell0@...il.com>,
	Frederic Weisbecker <frederic@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	John Stultz <jstultz@...gle.com>, linux-usb@...r.kernel.org,
	Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
	Matthew Wilcox <willy@...radead.org>,
	Tamir Duberstein <tamird@...il.com>
Subject: Re: [PATCH 00/46] Allow inlining C helpers into Rust when using LTO

On Tue, Dec 02, 2025 at 07:37:24PM +0000, Alice Ryhl wrote:
> This patch series adds __rust_helper to every single rust helper. The
> patches do not depend on each other, so maintainers please go ahead and
> pick up any patches relevant to your subsystem! Or provide your Acked-by
> so that Miguel can pick them up.
> 
> These changes were generated by adding __rust_helper and running
> ClangFormat. Unrelated formatting changes were removed manually.
> 
> Why is __rust_helper needed?
> ============================
> 
> Currently, C helpers cannot be inlined into Rust even when using LTO
> because LLVM detects slightly different options on the codegen units.
> 
> * LLVM doesn't want to inline functions compiled with
>   `-fno-delete-null-pointer-checks` with code compiled without. The C
>   CGUs all have this enabled and Rust CGUs don't. Inlining is okay since
>   this is one of the hardening features that does not change the ABI,
>   and we shouldn't have null pointer dereferences in these helpers.
> 
> * LLVM doesn't want to inline functions with different list of builtins. C
>   side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so
>   they should be compatible, but LLVM does not perform inlining due to
>   attributes mismatch.
> 
> * clang and Rust doesn't have the exact target string. Clang generates
>   `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will
>   complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64
>   always enable these features, so they are in fact the same target
>   string, but LLVM doesn't understand this and so inlining is inhibited.
>   This can be bypassed with `--ignore-tti-inline-compatible`, but this
>   is a hidden option.
> 
> (This analysis was written by Gary Guo.)
> 
> How is this fixed?
> ==================
> 
> To fix this we need to add __always_inline to all helpers when compiling
> with LTO. However, it should not be added when running bindgen as
> bindgen will ignore functions marked inline. To achieve this, we are
> using a #define called __rust_helper that is defined differently
> depending on whether bindgen is running or not.
> 
> Note that __rust_helper is currently always #defined to nothing.
> Changing it to __always_inline will happen separately in another patch
> series.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>

For the whole series:

Reviewed-by: Boqun Feng <boqun.feng@...il.com>

Regards,
Boqun

> ---
[...]

Powered by blists - more mailing lists