Re: [PATCH v3 01/21] rust: transmute: add `cast_slice[_mut]` functions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `# Safety` contract for `cast_slice` and `cast_slice_mut` is incomplete, omitting critical requirements regarding bit-pattern validity and interior mutability.
- [Low] The small abstraction functions `cast_slice` and `cast_slice_mut` are missing `#[inline]` attributes.
- [Low] Import formatting does not follow the kernel vertical import style.
--

commit d8c311b266bb9a64cb5ebd99f708e41b6412ae21
Author: Benno Lossin <lossin@kernel.org>

rust: transmute: add cast_slice[_mut] functions

This commit introduces functions to enable casting slices with only a single
unsafe block.

Message-ID: <20250814124424.516191-2-lossin@kernel.org>

> diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
> index 654b5ede2fe29..c1282fcc9e651 100644
> --- a/rust/kernel/transmute.rs
> +++ b/rust/kernel/transmute.rs
> @@ -3,6 +3,7 @@
>  //! Traits for transmuting types.
>  
>  use core::mem::size_of;
> +use core::slice;

[Severity: Low]
Is this import formatting intentional? The subsystem coding guidelines
specify following the kernel vertical import style, which would group this
with the existing core import as use core::{mem::size_of, slice};.

[ ... ]

> +/// # Safety
> +///
> +/// - T and U must have the same layout.

[Severity: High]
Is this safety contract complete? It appears to omit requirements regarding
bit-pattern validity and interior mutability. For example, if a caller uses
types where values of T are not valid bit-patterns for U, could this lead
to undefined behavior despite adhering to the stated layout constraint?

> +pub unsafe fn cast_slice<T, U>(slice: &[T]) -> &[U] {

[Severity: Low]
Does this function need an inline attribute? As a small abstraction wrapper
forwarding to standard library slice functions within the kernel crate, the
guidelines indicate it should be annotated with #[inline] to ensure optimal
code generation across crate boundaries.

[ ... ]

> +/// # Safety
> +///
> +/// - T and U must have the same layout.

[Severity: High]
Does the mutable variant's safety contract also need to specify bit-pattern
validity in both directions? If a caller writes a valid U that is an
invalid bit-pattern for T, it seems this could cause undefined behavior
when the slice reverts to a mutable slice of T. Should it also explicitly
forbid introducing interior mutability?

> +pub unsafe fn cast_slice_mut<T, U>(slice: &mut [T]) -> &mut [U] {

[Severity: Low]
As with cast_slice, should this thin abstraction wrapper also include the
#[inline] attribute?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901010347.2614656-1-alistair.francis@wdc.com?part=1