linux-kernel - Re: [PATCH v2] rust: sync: optimize rust symbol generation for CondVar

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: <CANiq72=iMaEOALbh8EBrgEc5t0KQ2BTPADro3vmBtEM75pO3aw@mail.gmail.com>
Date: Tue, 25 Mar 2025 11:12:59 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Kunwu Chan <kunwu.chan@...ux.dev>
Cc: ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com, 
	gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, 
	a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu, 
	dakr@...nel.org, nathan@...nel.org, nick.desaulniers+lkml@...il.com, 
	morbo@...gle.com, justinstitt@...gle.com, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, 
	Kunwu Chan <kunwu.chan@...mail.com>, Grace Deng <Grace.Deng006@...il.com>
Subject: Re: [PATCH v2] rust: sync: optimize rust symbol generation for CondVar

On Tue, Mar 25, 2025 at 4:02 AM Kunwu Chan <kunwu.chan@...ux.dev> wrote:
>
> Thanks for the kind reminder, I'll follow this next time

You're welcome!

> Now, the default '-Copt-level' is 2 when define
> 'CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE',
> and in  KBUILD_RUSTFLAGS the  '-Ccodegen-units' is 1.
>
> So if the config not change, the result should be the same.

I don't think that is true, because there are a few `rustc` versions
as well as LLVM ones that we support, so how inlining happens (at both
`rustc` and LLVM levels) may change even if the configuration is
essentially the same.

And, of course, then there are other non-compiler-related kernel
config options (i.e. not compiler flags, but other stuff, like `cfg`s)
that influence which and how gets emitted and thus the inlining
decisions.

Eventually we should have pure GCC builds too, which is yet another factor...

To be clear, I agree with Boqun that having to write `#[inline]`
everywhere is not great. Rust 1.75 already started to tag small
functions as `#[inline]` to try to prevent the proliferation of the
attribute, which is good (i.e. which is what triggered the message in
Compiler Explorer).

By the way, one difference is whether it is `pub` -- the `notify()`
isn't (unlike the others), but if it were, then we would have needed
the `#[inline]`, from a quick test.

Thanks!

Cheers,
Miguel