From: Robin Murphy <robin.murphy@arm.com>
To: Daniel Almeida <daniel.almeida@collabora.com>,
Alice Ryhl <aliceryhl@google.com>
Cc: "Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Valentin Obst" <kernel@valentinobst.de>,
"open list" <linux-kernel@vger.kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
airlied@redhat.com,
"open list:DMA MAPPING HELPERS" <iommu@lists.linux.dev>
Subject: Re: [PATCH v7 2/2] rust: add dma coherent allocator abstraction.
Date: Fri, 13 Dec 2024 15:28:18 +0000 [thread overview]
Message-ID: <b7130ae2-6314-41d9-bda2-d875b22463bb@arm.com> (raw)
In-Reply-To: <0F719804-2AD3-4C4E-A98C-2862295990BA@collabora.com>
On 13/12/2024 2:47 pm, Daniel Almeida wrote:
[...]
>>> + /// Returns the CPU-addressable region as a slice.
>>> + pub fn cpu_buf(&self) -> &[T]
>>> + {
>>> + // SAFETY: The pointer is valid due to type invariant on `CoherentAllocation` and
>>> + // is valid for reads for `self.count * size_of::<T>` bytes.
>>> + unsafe { core::slice::from_raw_parts(self.cpu_addr, self.count) }
>>
>> Immutable slices require that the data does not change while the
>> reference is live. Is that the case? If so, your safety comment should
>> explain that.
>>
>>> + }
>>> +
>>> + /// Performs the same functionality as `cpu_buf`, except that a mutable slice is returned.
>>> + pub fn cpu_buf_mut(&mut self) -> &mut [T]
>>> + {
>>> + // SAFETY: The pointer is valid due to type invariant on `CoherentAllocation` and
>>> + // is valid for reads for `self.count * size_of::<T>` bytes.
>>> + unsafe { core::slice::from_raw_parts_mut(self.cpu_addr, self.count) }
>>
>> Mutable slices require that the data is not written to *or read* by
>> anybody else while the reference is live. Is that the case? If so,
>> your safety comment should explain that.
>>
>
> The buffer will probably be shared between the CPU and some hardware device, since this is the
> point of the dma mapping API.
>
> It’s up to the caller to ensure that no hardware operations that involve the buffer are currently taking
> place while the slices above are alive.
Hmm, that sounds troublesome... the nature of coherent allocations is
that both CPU and device may access them at any time, and you can
definitely expect ringbuffer-style usage models where a CPU is writing
to part of the buffer while the device is reading/writing another part,
but also cases where a CPU needs to poll for a device write to a
particular location.
Thanks,
Robin.
> I think that adding that as a safety requirement to `cpu_buf` and `cpu_buf_mut` will be sufficient.
>
>>> + }
>>> +}
>>> +
>>> +impl<T: AsBytes + FromBytes> Drop for CoherentAllocation<T> {
>>> + fn drop(&mut self) {
>>> + let size = self.count * core::mem::size_of::<T>();
>>> + // SAFETY: the device, cpu address, and the dma handle is valid due to the
>>> + // type invariants on `CoherentAllocation`.
>>> + unsafe { bindings::dma_free_attrs(self.dev.as_raw(), size,
>>> + self.cpu_addr as _,
>>> + self.dma_handle,
>>> + self.dma_attrs.as_raw(),) }
>>> + }
>>> +}
>>> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
>>> index e1065a7551a3..6e90ebf5a130 100644
>>> --- a/rust/kernel/lib.rs
>>> +++ b/rust/kernel/lib.rs
>>> @@ -35,6 +35,7 @@
>>> mod build_assert;
>>> pub mod cred;
>>> pub mod device;
>>> +pub mod dma;
>>> pub mod error;
>>> #[cfg(CONFIG_RUST_FW_LOADER_ABSTRACTIONS)]
>>> pub mod firmware;
>>> —
>>> 2.43.0
>
> — Daniel
next prev parent reply other threads:[~2024-12-13 15:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 22:14 [PATCH v7 0/2] Add dma coherent allocator abstraction Abdiel Janulgue
2024-12-10 22:14 ` [PATCH v7 1/2] rust: error: Add EOVERFLOW Abdiel Janulgue
2024-12-10 22:14 ` [PATCH v7 2/2] rust: add dma coherent allocator abstraction Abdiel Janulgue
2024-12-13 8:53 ` Abdiel Janulgue
2024-12-19 11:22 ` Andreas Hindborg
2025-01-08 12:26 ` Abdiel Janulgue
2025-01-09 8:44 ` Andreas Hindborg
2024-12-13 14:12 ` Daniel Almeida
2024-12-13 14:27 ` Alice Ryhl
2024-12-13 14:47 ` Daniel Almeida
2024-12-13 15:28 ` Robin Murphy [this message]
2024-12-13 19:08 ` Daniel Almeida
2024-12-16 10:23 ` Abdiel Janulgue
2024-12-16 11:00 ` Daniel Almeida
2024-12-16 10:28 ` Abdiel Janulgue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7130ae2-6314-41d9-bda2-d875b22463bb@arm.com \
--to=robin.murphy@arm.com \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=airlied@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=kernel@valentinobst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox