From: Abdiel Janulgue <abdiel.janulgue@gmail.com>
To: Alexandre Courbot <acourbot@nvidia.com>,
a.hindborg@kernel.org, benno.lossin@proton.me,
rust-for-linux@vger.kernel.org
Cc: "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>,
"Alice Ryhl" <aliceryhl@google.com>,
"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>,
"Robin Murphy" <robin.murphy@arm.com>,
airlied@redhat.com,
"open list:DMA MAPPING HELPERS" <iommu@lists.linux.dev>
Subject: Re: [PATCH v2 3/3] rust: dma: add as_slice/write functions for CoherentAllocation
Date: Thu, 10 Apr 2025 13:47:59 +0300 [thread overview]
Message-ID: <dbfad5a9-7e31-4674-b1e4-9d0ad55b64e4@gmail.com> (raw)
In-Reply-To: <D92VBJWRTE2N.1O4IA5X7I1YFS@nvidia.com>
On 10/04/2025 12:57, Alexandre Courbot wrote:
> Hi Abdiel,
>
> On Thu Apr 10, 2025 at 5:58 PM JST, Abdiel Janulgue wrote:
>> Add unsafe accessors for the region for reading or writing large
>> blocks of data.
>>
>> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com>
>> ---
>> rust/kernel/dma.rs | 85 ++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
>> index a61da5eeb017..880f6f04ba86 100644
>> --- a/rust/kernel/dma.rs
>> +++ b/rust/kernel/dma.rs
>> @@ -218,6 +218,91 @@ 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.
>> + ///
>> + /// For ringbuffer type of r/w access or use-cases where the pointer to the live data is needed,
>> + /// [`CoherentAllocation::start_ptr`] or [`CoherentAllocation::start_ptr_mut`] could be used instead.
>> + ///
>> + /// # Safety
>> + ///
>> + /// * Callers must ensure that the device does not read/write to/from memory 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);
>> + }
>
> Not sure if you have overlooked my comment on the previous iteration or
> if I completely missed the mark, but my understanding if that the bound
> check should be `if end > self.count`. Also applies to the other methods
> of this patch.
>
Ah sorry about that, just missed that part! But will definitely do a
follow-up that includes this (with other changes if needed).
/Abdiel
prev parent reply other threads:[~2025-04-10 10:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 8:58 [PATCH v2 0/3] Additional improvements for dma coherent allocator Abdiel Janulgue
2025-04-10 8:58 ` [PATCH v2 1/3] rust: dma: clarify wording and be consistent in `coherent` nomenclature Abdiel Janulgue
2025-04-10 8:58 ` [PATCH v2 2/3] rust: dma: convert the read/write macros to return Result Abdiel Janulgue
2025-04-10 11:21 ` Danilo Krummrich
2025-04-10 11:54 ` Danilo Krummrich
2025-04-10 15:11 ` Benno Lossin
2025-04-10 15:34 ` Danilo Krummrich
2025-04-10 8:58 ` [PATCH v2 3/3] rust: dma: add as_slice/write functions for CoherentAllocation Abdiel Janulgue
2025-04-10 9:57 ` Alexandre Courbot
2025-04-10 10:47 ` Abdiel Janulgue [this message]
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=dbfad5a9-7e31-4674-b1e4-9d0ad55b64e4@gmail.com \
--to=abdiel.janulgue@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.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=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=robin.murphy@arm.com \
--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
all inboxes | Powered by JetHome®