linux-kernel - Re: [PATCH 1/4] rust: dma: implement DataDirection

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: <CAH5fLgi6OZaqjnDScDrJ3YjN2a8mJuPiO5MLPUqUWo62WkvvrA@mail.gmail.com>
Date: Mon, 18 Aug 2025 16:00:27 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: akpm@...ux-foundation.org, ojeda@...nel.org, alex.gaynor@...il.com, 
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
	lossin@...nel.org, a.hindborg@...nel.org, tmgross@...ch.edu, 
	abdiel.janulgue@...il.com, acourbot@...dia.com, jgg@...pe.ca, 
	lyude@...hat.com, robin.murphy@....com, daniel.almeida@...labora.com, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] rust: dma: implement DataDirection

On Mon, Aug 18, 2025 at 2:57 PM Danilo Krummrich <dakr@...nel.org> wrote:
>
> On Mon Aug 18, 2025 at 2:22 PM CEST, Alice Ryhl wrote:
> > On Mon, Aug 18, 2025 at 01:27:44PM +0200, Danilo Krummrich wrote:
> >> On Mon Aug 18, 2025 at 11:34 AM CEST, Alice Ryhl wrote:
> >> > On Fri, Aug 15, 2025 at 07:10:02PM +0200, Danilo Krummrich wrote:
> >> >> Add the `DataDirection` struct, a newtype wrapper around the C
> >> >> `enum dma_data_direction`.
> >> >>
> >> >> This provides a type-safe Rust interface for specifying the direction of
> >> >> DMA transfers.
> >> >>
> >> >> Signed-off-by: Danilo Krummrich <dakr@...nel.org>
> >> >
> >> >> +/// DMA data direction.
> >> >> +///
> >> >> +/// Corresponds to the C [`enum dma_data_direction`].
> >> >> +///
> >> >> +/// [`enum dma_data_direction`]: srctree/include/linux/dma-direction.h
> >> >> +#[derive(Copy, Clone, PartialEq, Eq)]
> >> >> +pub struct DataDirection(bindings::dma_data_direction);
> >> >
> >> > Perhaps this should be a real Rust enum so that you can do an exhaustive
> >> > match?
> >>
> >>      /// DMA data direction.
> >>      ///
> >>      /// Corresponds to the C [`enum dma_data_direction`].
> >>      ///
> >>      /// [`enum dma_data_direction`]: srctree/include/linux/dma-direction.h
> >>      #[derive(Copy, Clone, PartialEq, Eq, Debug)]
> >>      #[repr(i32)]
> >>
> >> Does bindgen ever pick another type than i32 for C enums? If so, it'd be a
> >> downside that we'd have to mess with the type either in the `repr` or by casting
> >> the variants.
> >>
> >>      pub enum DataDirection {
> >>          /// The DMA mapping is for bidirectional data transfer.
> >>          ///
> >>          /// This is used when the buffer can be both read from and written to by the device.
> >>          /// The cache for the corresponding memory region is both flushed and invalidated.
> >>          Bidirectional = bindings::dma_data_direction_DMA_BIDIRECTIONAL,
> >>
> >>          /// The DMA mapping is for data transfer from memory to the device (write).
> >>          ///
> >>          /// The CPU has prepared data in the buffer, and the device will read it.
> >>          /// The cache for the corresponding memory region is flushed.
> >>          ToDevice = bindings::dma_data_direction_DMA_TO_DEVICE,
> >>
> >>          /// The DMA mapping is for data transfer from the device to memory (read).
> >>          ///
> >>          /// The device will write data into the buffer for the CPU to read.
> >>          /// The cache for the corresponding memory region is invalidated before CPU access.
> >>          FromDevice = bindings::dma_data_direction_DMA_FROM_DEVICE,
> >>
> >>          /// The DMA mapping is not for data transfer.
> >>          ///
> >>          /// This is primarily for debugging purposes. With this direction, the DMA mapping API
> >>          /// will not perform any cache coherency operations.
> >>          None = bindings::dma_data_direction_DMA_NONE,
> >>      }
> >>
> >>      impl From<DataDirection> for bindings::dma_data_direction {
> >>          /// Returns the raw representation of [`enum dma_data_direction`].
> >>          fn from(direction: DataDirection) -> Self {
> >>              direction as Self
> >>          }
> >>      }
> >
> > My suggestion is to cast on the Rust-side.
> >
> > #[repr(whateveryouwant)]
>
> What's your suggestion for whateveryouwant?
>
> And I mean this in general, not only for this case of dma::DataDirection. If we
> pick u32 than things break if a negative enum variant is added on the C side. If
> we pick i32, it can happen that we overflow.
>
> > enum DataDirection {
> >     Bidirectional = bindings::dma_data_direction_DMA_BIDIRECTIONAL as _,
>
> We have a clippy lint that warns about `as _` casts, but I guess you meant
> `as whateveryouwant`. However, if bindgen picks whateveryouwant too, we also get
> a warning.
>
> Ultimately, we'd need to suppress a warning.

In general, I think we want some sort of helper function to cast
between arbitrary integer types in const-evaluation that panics if the
cast is out of bounds. Both here and many other places.

Alice