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: <CANiq72miL3eZ40ujmA-pXCqMS8y2AzJQ1UKpL1_hX03AJ0fteQ@mail.gmail.com>
Date: Thu, 1 May 2025 21:26:24 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
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

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.

Cheers,
Miguel