[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87friihloe.fsf@kernel.org>
Date: Tue, 08 Apr 2025 14:39:29 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Abdiel Janulgue" <abdiel.janulgue@...il.com>
Cc: <ojeda@...nel.org>, "Danilo Krummrich" <dakr@...nel.org>, "Daniel
Almeida" <daniel.almeida@...labora.com>, "Robin Murphy"
<robin.murphy@....com>, "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"
<benno.lossin@...ton.me>, "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor
Gross" <tmgross@...ch.edu>, <rust-for-linux@...r.kernel.org>, "Marek
Szyprowski" <m.szyprowski@...sung.com>, <iommu@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] rust: dma: add as_slice/write functions for
CoherentAllocation
"Abdiel Janulgue" <abdiel.janulgue@...il.com> writes:
> Add unsafe accessors for the region for reading or writing large
> blocks of data.
>
> Reviewed-by: Andreas Hindborg <a.hindborg@...nel.org>
> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@...il.com>
> ---
> rust/kernel/dma.rs | 87 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 24a6f10370c4..24025ec602ff 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -218,6 +218,93 @@ pub fn dma_handle(&self) -> bindings::dma_addr_t {
> self.dma_handle
> }
>
> + /// Returns the data from the region starting from `offset` as a slice.
> + /// `offset` and `count` are in units of `T`, not the number of bytes.
> + ///
> + /// Due to the safety requirements of slice, the caller should consider that the region could
> + /// be modified by the device at anytime.
The user does not need to consider this, because the safety requirements
make sure this is not a problem. The user only needs to consider the
safety requirements.
>> For ringbuffer type of r/w access or use-cases where
> + /// the pointer to the live data is needed, `start_ptr()` or `start_ptr_mut()` could be
> + /// used instead.
> + ///
> + /// # Safety
> + ///
> + /// * Callers must ensure that no hardware operations that involve the buffer are currently
> + /// taking place while the returned slice is live.
> + /// * Callers must ensure that this call does not race with a write to the same region while
> + /// while the returned slice is live.
> + pub unsafe fn as_slice(&self, offset: usize, count: usize) -> Result<&[T]> {
> + let end = offset.checked_add(count).ok_or(EOVERFLOW)?;
> + if end >= self.count {
> + return Err(EINVAL);
> + }
> + // SAFETY:
> + // - The pointer is valid due to type invariant on `CoherentAllocation`,
> + // we've just checked that the range and index is within bounds. The immutability of the
> + // of data is also guaranteed by the safety requirements of the function.
> + // - `offset` can't overflow since it is smaller than `self.count` and we've checked
> + // that `self.count` won't overflow early in the constructor.
> + Ok(unsafe { core::slice::from_raw_parts(self.cpu_addr.add(offset), count) })
> + }
> +
> + /// Performs the same functionality as [`CoherentAllocation::as_slice`], except that a mutable
> + /// slice is returned.
> + ///
> + /// # Safety
> + ///
> + /// * Callers must ensure that no hardware operations that involve the buffer are currently
> + /// taking place while the returned slice is live.
> + /// * Callers must ensure that this call does not race with a read or write to the same region
> + /// while the returned slice is live.
> + pub unsafe fn as_slice_mut(&self, offset: usize, count: usize) -> Result<&mut [T]> {
> + let end = offset.checked_add(count).ok_or(EOVERFLOW)?;
> + if end >= self.count {
> + return Err(EINVAL);
> + }
> + // SAFETY:
> + // - The pointer is valid due to type invariant on `CoherentAllocation`,
> + // we've just checked that the range and index is within bounds. The immutability of the
> + // of data is also guaranteed by the safety requirements of the function.
Formatting nit: could you indent the paragraph under the bullet:
- The pointer is valid due to type invariant on `CoherentAllocation`,
we've just checked that the range and index is within bounds. The immutability of the
of data is also guaranteed by the safety requirements of the function.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists