From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: Gary Guo <gary@garyguo.net>, Alice Ryhl <aliceryhl@google.com>,
mmaurer@google.com, Danilo Krummrich <dakr@kernel.org>,
Joel Fernandes <joelagnelf@nvidia.com>,
rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH v8 3/7] rust: dma: implement BinaryWriter for CoherentAllocation<u8>
Date: Fri, 13 Mar 2026 11:11:29 +0900 [thread overview]
Message-ID: <DH1AG9IDZIDO.2610KTTZ29MVS@nvidia.com> (raw)
In-Reply-To: <20260310220000.1897166-4-ttabi@nvidia.com>
On Wed Mar 11, 2026 at 6:59 AM JST, Timur Tabi wrote:
> Implement the BinaryWriter trait for CoherentAllocation<u8>, enabling
> DMA coherent allocations to be exposed as readable binary files.
> The implementation handles offset tracking and bounds checking, copying
> data from the coherent allocation to userspace via write_dma().
>
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>
> ---
> rust/kernel/dma.rs | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 909d56fd5118..b1cc39756dd8 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -5,12 +5,14 @@
> //! C header: [`include/linux/dma-mapping.h`](srctree/include/linux/dma-mapping.h)
>
> use crate::{
> - bindings, build_assert, device,
> + bindings, build_assert, debugfs, device,
> device::{Bound, Core},
> error::{to_result, Result},
> + fs::file,
> prelude::*,
> sync::aref::ARef,
> transmute::{AsBytes, FromBytes},
> + uaccess::UserSliceWriter,
> };
> use core::ptr::NonNull;
>
> @@ -668,6 +670,38 @@ fn drop(&mut self) {
> // can be sent to another thread.
> unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
>
> +// SAFETY: Sharing `&CoherentAllocation` across threads is safe if `T` is `Sync`, because all
> +// methods that access the buffer contents (`field_read`, `field_write`, `as_slice`,
> +// `as_slice_mut`) are `unsafe`, and callers are responsible for ensuring no data races occur.
> +// The safe methods only return metadata or raw pointers whose use requires `unsafe`.
> +unsafe impl<T: AsBytes + FromBytes + Sync> Sync for CoherentAllocation<T> {}
> +
> +impl debugfs::BinaryWriter for CoherentAllocation<u8> {
> + fn write_to_slice(
> + &self,
> + writer: &mut UserSliceWriter,
> + offset: &mut file::Offset,
> + ) -> Result<usize> {
> + if offset.is_negative() {
> + return Err(EINVAL);
> + }
Won't the `try_into` right below also reject negative values?
> +
> + let offset_val: usize = (*offset).try_into().map_err(|_| EINVAL)?;
> + let len = self.count();
> +
> + if offset_val >= len {
> + return Ok(0);
> + }
> +
> + let count = (len - offset_val).min(writer.len());
We can simplify a bit:
let count = self.count().saturating_sub(offset_val).min(writer.len());
That way you can get rid of the `offset_val >= len`` test and the rest
of the code will work with `len == 0`, which will have the desired
effect.
Regardless,
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
WARNING: multiple messages have this Message-ID (diff)
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: "Gary Guo" <gary@garyguo.net>,
"Alice Ryhl" <aliceryhl@google.com>, <mmaurer@google.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
<rust-for-linux@vger.kernel.org>, <nouveau@lists.freedesktop.org>
Subject: Re: [PATCH v8 3/7] rust: dma: implement BinaryWriter for CoherentAllocation<u8>
Date: Fri, 13 Mar 2026 11:11:29 +0900 [thread overview]
Message-ID: <DH1AG9IDZIDO.2610KTTZ29MVS@nvidia.com> (raw)
In-Reply-To: <20260310220000.1897166-4-ttabi@nvidia.com>
On Wed Mar 11, 2026 at 6:59 AM JST, Timur Tabi wrote:
> Implement the BinaryWriter trait for CoherentAllocation<u8>, enabling
> DMA coherent allocations to be exposed as readable binary files.
> The implementation handles offset tracking and bounds checking, copying
> data from the coherent allocation to userspace via write_dma().
>
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>
> ---
> rust/kernel/dma.rs | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 909d56fd5118..b1cc39756dd8 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -5,12 +5,14 @@
> //! C header: [`include/linux/dma-mapping.h`](srctree/include/linux/dma-mapping.h)
>
> use crate::{
> - bindings, build_assert, device,
> + bindings, build_assert, debugfs, device,
> device::{Bound, Core},
> error::{to_result, Result},
> + fs::file,
> prelude::*,
> sync::aref::ARef,
> transmute::{AsBytes, FromBytes},
> + uaccess::UserSliceWriter,
> };
> use core::ptr::NonNull;
>
> @@ -668,6 +670,38 @@ fn drop(&mut self) {
> // can be sent to another thread.
> unsafe impl<T: AsBytes + FromBytes + Send> Send for CoherentAllocation<T> {}
>
> +// SAFETY: Sharing `&CoherentAllocation` across threads is safe if `T` is `Sync`, because all
> +// methods that access the buffer contents (`field_read`, `field_write`, `as_slice`,
> +// `as_slice_mut`) are `unsafe`, and callers are responsible for ensuring no data races occur.
> +// The safe methods only return metadata or raw pointers whose use requires `unsafe`.
> +unsafe impl<T: AsBytes + FromBytes + Sync> Sync for CoherentAllocation<T> {}
> +
> +impl debugfs::BinaryWriter for CoherentAllocation<u8> {
> + fn write_to_slice(
> + &self,
> + writer: &mut UserSliceWriter,
> + offset: &mut file::Offset,
> + ) -> Result<usize> {
> + if offset.is_negative() {
> + return Err(EINVAL);
> + }
Won't the `try_into` right below also reject negative values?
> +
> + let offset_val: usize = (*offset).try_into().map_err(|_| EINVAL)?;
> + let len = self.count();
> +
> + if offset_val >= len {
> + return Ok(0);
> + }
> +
> + let count = (len - offset_val).min(writer.len());
We can simplify a bit:
let count = self.count().saturating_sub(offset_val).min(writer.len());
That way you can get rid of the `offset_val >= len`` test and the rest
of the code will work with `len == 0`, which will have the desired
effect.
Regardless,
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
next prev parent reply other threads:[~2026-03-13 2:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 21:59 [PATCH v8 0/7] gpu: nova-core: expose the logging buffers via debugfs Timur Tabi
2026-03-10 21:59 ` [PATCH v8 1/7] rust: device: add device name method Timur Tabi
2026-03-10 22:05 ` Alice Ryhl
2026-03-10 22:05 ` Alice Ryhl
2026-03-13 2:10 ` Alexandre Courbot
2026-03-13 2:10 ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 2/7] rust: uaccess: add write_dma() for copying from DMA buffers to userspace Timur Tabi
2026-03-11 5:48 ` kernel test robot
2026-03-13 2:11 ` Alexandre Courbot
2026-03-13 2:11 ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 3/7] rust: dma: implement BinaryWriter for CoherentAllocation<u8> Timur Tabi
2026-03-13 2:11 ` Alexandre Courbot [this message]
2026-03-13 2:11 ` Alexandre Courbot
2026-03-14 2:05 ` Timur Tabi
2026-03-14 2:05 ` Timur Tabi
2026-03-15 5:11 ` Alexandre Courbot
2026-03-15 5:11 ` Alexandre Courbot
2026-03-15 18:57 ` Timur Tabi
2026-03-15 18:57 ` Timur Tabi
2026-03-16 3:44 ` Alexandre Courbot
2026-03-16 3:44 ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 4/7] gpu: nova-core: Replace module_pci_driver! with explicit module init Timur Tabi
2026-03-10 21:59 ` [PATCH v8 5/7] gpu: nova-core: use pin projection in method boot() Timur Tabi
2026-03-13 2:13 ` Alexandre Courbot
2026-03-13 2:13 ` Alexandre Courbot
2026-03-14 2:20 ` Timur Tabi
2026-03-14 2:20 ` Timur Tabi
2026-03-10 21:59 ` [PATCH v8 6/7] gpu: nova-core: create debugfs root in module init Timur Tabi
2026-03-10 22:00 ` [PATCH v8 7/7] gpu: nova-core: create GSP-RM logging buffers debugfs entries Timur Tabi
2026-03-10 22:20 ` [PATCH v8 0/7] gpu: nova-core: expose the logging buffers via debugfs John Hubbard
2026-03-12 3:50 ` John Hubbard
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=DH1AG9IDZIDO.2610KTTZ29MVS@nvidia.com \
--to=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=joelagnelf@nvidia.com \
--cc=mmaurer@google.com \
--cc=nouveau@lists.freedesktop.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=ttabi@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.