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

Message-ID: <d193a3bb-8faf-4741-88c3-0173fa36b209@linux.dev>
Date: Wed, 26 Mar 2025 09:48:07 +0800
From: Kunwu Chan <kunwu.chan@...ux.dev>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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 2025/3/25 18:12, Miguel Ojeda wrote:
> 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).

Thanks for the detailed reply.

Sure on the one hand, the decisions is a result of many factors,

on the other hand the rustc and llvm is rapidly developing.

It's a complicated thing.

> 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.
That is a easy way to judge. I learned.
> Thanks!
>
> Cheers,
> Miguel

-- 
Thanks,
   Kunwu.Chan(Tao.Chan)