linux-kernel - Re: [PATCH v6 1/3] rust: configfs: introduce rust support for configfs

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: <87bjsc154u.fsf@kernel.org>
Date: Thu, 01 May 2025 21:51:29 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Danilo Krummrich" <dakr@...nel.org>,  "Miguel Ojeda"
 <ojeda@...nel.org>,  "Alex Gaynor" <alex.gaynor@...il.com>,  "Boqun Feng"
 <boqun.feng@...il.com>,  "Gary Guo" <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Benno Lossin" <benno.lossin@...ton.me>,
  "Alice Ryhl" <aliceryhl@...gle.com>,  "Trevor Gross" <tmgross@...ch.edu>,
  "Joel Becker" <jlbec@...lplan.org>,  "Peter Zijlstra"
 <peterz@...radead.org>,  "Ingo Molnar" <mingo@...hat.com>,  "Will Deacon"
 <will@...nel.org>,  "Waiman Long" <longman@...hat.com>,  "Fiona Behrens"
 <me@...enk.dev>,  "Charalampos Mitrodimas" <charmitro@...teo.net>,
  "Daniel Almeida" <daniel.almeida@...labora.com>,  "Breno Leitao"
 <leitao@...ian.org>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/3] rust: configfs: introduce rust support for configfs

"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:

> On Thu, May 1, 2025 at 8:11 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>> But why does that matter? Anything in the commit message after the cut
>> is dropped when applying the patch, right?
>
> Yes, but it is not common to add a newline there. I mentioned it
> because it looked odd, no worries.
>
>> I might not have the full picture, but it is my understanding that
>> while `const fn` are evaluated in const context when called from const
>> context, they _may_ be called from non-const context, and then they are
>> evaluated in non-const context if their arguments are not const [1].
>> They are not guaranteed to be evaluated in const context.
>>
>> So my thinking is that down the road, refactoring of this code may cause
>> the `AttributeList::add` to be called in a way so that it is not
>> evaluated in const context, and then the `assert` would be evaluated at
>> run time. With `build_error` we would get an error during build.
>
> No, it will always be evaluated at compile-time (if it is evaluated at all).
>
> Please see again the links I provided. There is no `const fn` in the
> example I provided, and yet it is a build error.
>
> From your link, it is clear `const` blocks are a const context, which
> are always evaluated at compile time:
>
>     Certain forms of expressions, called constant expressions, can be
>     evaluated at compile time.
>
>     In const contexts, these are the only allowed expressions, and are
>     always evaluated at compile time.
>
>     A const context is one of the following: (...) A const block
>
> And from mine, it mentions that it is guaranteed to be evaluated if
> execution reaches that point and that such evaluation would happen at
> compile time:
>
>     A const block is a variant of a block expression whose body
>     evaluates at compile-time instead of at runtime.
>
>     If the const block expression is executed at runtime, then the
>     constant is guaranteed to be evaluated, even if its return value is
>     ignored:
>
>         fn foo<T>() -> usize {
>             // If this code ever gets executed, then the assertion has
>             // definitely been evaluated at compile-time.
>             const { assert!(std::mem::size_of::<T>() > 0); }
>             // Here we can have unsafe code relying on the type being
>             // non-zero-sized.
>             /* ... */
>             42
>         }
>
> That example they give is precisely about using a `const` block for
> guaranteeing something that unsafe code relies on.
>
> I hope that helps.

Ah - I understand. I missed that you wrapped the assert in a const
block, a quite important bit 🤦 Thanks for explaining!


Best regards,
Andreas Hindborg