[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aIzF1dMtIVXN0pDj@fedora>
Date: Fri, 1 Aug 2025 19:19:09 +0530
From: Ritvik Gupta <ritvikfoss@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: 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 <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, skhan@...uxfoundation.org,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3] rust: kernel: introduce `unsafe_precondition_assert!`
macro
On Thu, Jul 31, 2025 at 01:42:42PM +0200, Miguel Ojeda wrote:
> On Thu, Jul 31, 2025 at 1:12 PM Ritvik Gupta <ritvikfoss@...il.com> wrote:
> >
> > +/// /// - `buf` must be non-null.
> > +/// /// - `buf` must be 16-byte aligned.
>
> We don't know since the full body is not shown, but it is likely this
> would need to also be a valid pointer, i.e. it may be an uncommon
> example.
I believe this is a valid use-case for `unsafe_precondition_assert!`.
Should we add similar example?
```cpu.rs
/// Creates a new [`CpuId`] from the given `id` without checking bounds.
///
/// # Safety
///
/// The caller must ensure that `id` is a valid CPU ID (i.e., `0 <= id < nr_cpu_ids()`).
#[inline]
pub unsafe fn from_u32_unchecked(id: u32) -> Self {
debug_assert!(id < nr_cpu_ids());
// Ensure the `id` fits in an [`i32`] as it's also representable that way.
debug_assert!(id <= i32::MAX as u32);
// INVARIANT: The function safety guarantees `id` is a valid CPU id.
Self(id)
}
```
> More importantly, could we have a user of the macro introduced in a
> second patch so that it gets already used?
I believe the `debug_assert!` calls inside the `unsafe fn`
(excluding 'const fn' and 'CONFIG_RUST_OVERFLOW_CHECKS' flag)
are the intended targets for `unsafe_precondition_assert!`.
A quick grep (`git grep -B 15 -A 10 "debug_assert"`),
I could find 6 relevant callers in `alloc/kvec.rs` (2) and `cpu.rs` (4),
unless I'm missing something.
I'll send another patch for this, after getting the example correct.
Thanks for the feedback :)
Powered by blists - more mailing lists