[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72n72jO9v5Yo380VXTyaKiKG58U67f8XCP_--g2fHzeAzw@mail.gmail.com>
Date: Tue, 2 Apr 2024 09:36:22 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Laine Taffin Altman <alexanderaltman@...com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>,
Alice Ryhl <aliceryhl@...gle.com>, Martin Rodriguez Reboredo <yakoyoku@...il.com>, stable@...r.kernel.org,
rust-for-linux@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] rust: init: remove impl Zeroable for Infallible
On Tue, Apr 2, 2024 at 3:53 AM Laine Taffin Altman
<alexanderaltman@...com> wrote:
>
> A type is inhabited if at least one valid value of that type exists; a type is uninhabited if no valid values of that type exist. The terms "inhabited" and "uninhabited" in this sense originate in type theory, a branch of mathematics.
>
> In Rust, producing an invalid value of any type is immediate undefined behavior (UB); this includes via zeroing memory. Therefore, since an uninhabited type has no valid values, producing any values at all for it is UB.
>
> The Rust standard library type `core::convert::Infallible` is uninhabited, by virtue of having been declared as an enum with no cases, which always produces uninhabited types in Rust.
>
> The current kernel code allows this UB to be triggered, for example by code like:
> `pr_info!("{}”, Box::<core::convert::Infallible>::init(kernel::init::zeroed())?);`
>
> Thus, remove the implementation of `Zeroable` for `Infallible`, thereby avoiding the UB.
Do you agree with replacing the last part here with "avoiding the
unsoundness issue" or similar instead?
i.e. there is no UB in the kernel (related to this), so it isn't
avoided in that sense. Of course, you mean that we avoid potential UB
to be written in the future, but I think it is useful to distinguish
between patches for "holes" in the extra layer of "protection" vs.
patches that actually triggered UB.
> + // SAFETY: These are inhabited ZSTs; there is nothing to zero and a valid value exists.
Typically we would add an empty line here, and we would put the SAFETY
comment below (i.e. closer to the code) while the rest above.
> + // Note: do not add uninhabited types (such as ! or Infallible) to this list; creating an instance of an uninhabited type is immediate undefined behavior.
Nit: this could use Markdown (`!`, `Infallible`).
Otherwise, apart from these nits and the formatting bit, it looks good to me.
If you could send a quick v4, that would be great, thanks a lot!
Cheers,
Miguel
Powered by blists - more mailing lists