linux-kernel - Re: [PATCH v1 0/3] rust: make various `alloc` functions `const fn`

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: <CANiq72mv2yiJW_AD-_F1JUP2QdJKGGg8SqZ5SgDWT2xc_tpbZg@mail.gmail.com>
Date: Sun, 20 Jul 2025 17:42:43 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Onur Özkan <work@...rozkan.dev>
Cc: Benno Lossin <lossin@...nel.org>, rust-for-linux@...r.kernel.org, dakr@...nel.org, 
	ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com, 
	gary@...yguo.net, bjorn3_gh@...tonmail.com, a.hindborg@...nel.org, 
	aliceryhl@...gle.com, tmgross@...ch.edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] rust: make various `alloc` functions `const fn`

On Sun, Jul 20, 2025 at 5:17 PM Onur Özkan <work@...rozkan.dev> wrote:
>
> Personally, I don't have a specific reason. I thought the change is
> harmless and might extend functionality for other people in the future.
> It could also (although less likely) help the compiler optimize things
> further.

I think it is OK -- even if we promise they are `const` and we have to
remove it in the future, it is fine, since there is no stable kernel
API. So that flexibility is another advantage of no promises there.

However, I am curious, in which cases it would help the compiler
optimize? The compiler already has the information on whether it could
actually be `const` and whether it can be evaluated at compile-time
and so on -- do you mean it has an effect on heuristics like inlining
or similar?

Thanks!

Cheers,
Miguel