linux-kernel - Re: [RFC PATCH V2 2/8] rust: Extend OPP bindings for the OPP table

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]

Date: Mon, 10 Jun 2024 10:30:01 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Manos Pitsidianakis <manos.pitsidianakis@...aro.org>
Cc: Viresh Kumar <viresh.kumar@...aro.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...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>, Andreas Hindborg <a.hindborg@...sung.com>, 
	linux-pm@...r.kernel.org, Vincent Guittot <vincent.guittot@...aro.org>, 
	Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>, rust-for-linux@...r.kernel.org, 
	Erik Schilling <erik.schilling@...aro.org>, Alex Benné e <alex.bennee@...aro.org>, 
	Joakim Bech <joakim.bech@...aro.org>, Rob Herring <robh@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V2 2/8] rust: Extend OPP bindings for the OPP table

On Fri, Jun 7, 2024 at 1:04 PM Manos Pitsidianakis
<manos.pitsidianakis@...aro.org> wrote:
>
> On Fri, 07 Jun 2024 12:12, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >+/// OPP search types.
> >+#[derive(Copy, Clone, Debug, Eq, PartialEq)]
> >+pub enum SearchType {
> >+    /// Search for exact value.
> >+    Exact,
> >+    /// Search for highest value less than equal to value.
> >+    Floor,
> >+    /// Search for lowest value greater than equal to value.
> >+    Ceil,
> >+}
>
> Seeing this enum made me think about memory layouts which are not stable
> in Rust and can change between compilations unless they have a specific
> `repr`.
>
> Not related to this series directly, has there been discussion about
> guaranteeing struct layouts in kernel APIs? It'd require a lot of things
> to happen to cause a problem (multiple users of an API in the kernel in
> separate compilation units maybe even compiled with different rustc
> versions).

If you have two compilation units A and B where A depends on B, then
part of the input to `rustc A` will be the metadata emitted by `rustc
B`, which contains enough information to ensure that they agree on the
layout of structs defined in B. The metadata format is unstable and
changes each rustc release, so you cannot mix different rustc
compilers.

Alice