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: <CANiq72nPMH06HURgZJN-o0GMmGdQQpFetm=S5SDEB+B+f0wefA@mail.gmail.com>
Date: Tue, 6 May 2025 13:18:31 +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 Mon, May 5, 2025 at 9:51 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>
> So I was thinking that because I am initializing a static with a let
> statement, it would run in const context. But I see that it is not
> actually guaranteed.

No, that is actually guaranteed, i.e. when initializing a static. But
you aren't initializing a static here, no? Which static are you
referring to? If you were, then the "normal" `assert!` would work,
because it would be a const context.

The `add` calls I see are just in the `let` statement, not
initializing any static:

            {
                const N: usize = 0usize;
                unsafe { CONFIGURATION_ATTRS.add::<N, 0,
_>(&CONFIGURATION_MESSAGE_ATTR) };
            }

So it also means this comment is wrong:

+        // SAFETY: This function is only called through the `configfs_attrs`
+        // macro. This ensures that we are evaluating the function in const
+        // context when initializing a static. As such, the reference created
+        // below will be exclusive.

Please double-check all this... :)

> Right. Which is why I opted for `build_error`. But with the `const`
> block solution you suggested is better.

I thought you opted for that because you thought the `assert!` would
only work if not refactored. What I tried to point out was that the
`assert!` wouldn't have worked even before the refactoring.

I hope that helps.

Cheers,
Miguel