Rust for Linux List
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Alexandre Courbot <acourbot@nvidia.com>,
	Danilo Krummrich <dakr@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	David Airlie <airlied@gmail.com>, Gary Guo <gary@garyguo.net>,
	Simona Vetter <simona@ffwll.ch>
Cc: Alistair Popple <apopple@nvidia.com>,
	Timur Tabi <ttabi@nvidia.com>,
	Eliot Courtney <ecourtney@nvidia.com>, Zhi Wang <zhiw@nvidia.com>,
	nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds
Date: Fri, 24 Jul 2026 11:10:38 -0700	[thread overview]
Message-ID: <e7ba2c90-6d4f-487e-bd25-56d568ba1f26@nvidia.com> (raw)
In-Reply-To: <20260724-falcon-dma-projections-v1-2-957028a7c0a7@nvidia.com>

On 7/24/26 4:10 AM, Alexandre Courbot wrote:
> The DMA transfer routine was computing the start of the DMA area by
> taking the handle to the beginning of the coherent allocation, and then
> adding the transfer's start offset. It then checked manually that the
> upper bound was valid.
> 
> Convert this to an I/O projection of the same region, which returns
> `ERANGE` if the passed range does not fit within the coherent
> allocation. This removes the need to perform arithmetic on DMA handles
> and to explicitly check for the bounds' validity.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>   drivers/gpu/nova-core/falcon.rs | 55 +++++++++++++++++------------------------
>   1 file changed, 23 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
> index cd05985f5ee6..344cb1487295 100644
> --- a/drivers/gpu/nova-core/falcon.rs
> +++ b/drivers/gpu/nova-core/falcon.rs
> @@ -12,6 +12,7 @@
>           DmaAddress, //
>       },
>       io::{
> +        io_project,
>           poll::read_poll_timeout,
>           register::{
>               RegisterBase,
> @@ -511,20 +512,31 @@ fn dma_wr(
>       ) -> Result {
>           const DMA_LEN: u32 = num::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>   
> +        // DMA transfers can only be done in units of 256 bytes. Compute how many such transfers we
> +        // need to perform.
> +        let num_transfers = load_offsets.len.div_ceil(DMA_LEN);
> +
>           // For IMEM, we want to use the start offset as a virtual address tag for each page, since
>           // code addresses in the firmware (and the boot vector) are virtual.
>           //
> -        // For DMEM we can fold the start offset into the DMA handle.
> +        // For DMEM, the start offset is folded into the DMA address.
>           let (src_start, dma_start) = match target_mem {
> -            FalconMem::ImemSecure | FalconMem::ImemNonSecure => {
> -                (load_offsets.src_start, dma_obj.dma_handle())
> -            }
> -            FalconMem::Dmem => (
> -                0,
> -                dma_obj.dma_handle() + DmaAddress::from(load_offsets.src_start),
> -            ),
> +            FalconMem::ImemSecure | FalconMem::ImemNonSecure => (load_offsets.src_start, 0),
> +            FalconMem::Dmem => (0, usize::from_safe_cast(load_offsets.src_start)),
>           };
> -        if dma_start % DmaAddress::from(DMA_LEN) > 0 {
> +
> +        let dma_handle = {

Sort of "conceptually pre-existing" problem, but "handle" doesn't
quite work as a name, because handles are supposed to be opaque
items that one just uses to find and refer to things.


And below, that is violated:

> +            // Upper limit of transfer is `(num_transfers * DMA_LEN) + load_offsets.src_start`.
> +            let dma_end = num_transfers
> +                .checked_mul(DMA_LEN)
> +                .and_then(|size| size.checked_add(load_offsets.src_start))
> +                .map(usize::from_safe_cast)
> +                .ok_or(EOVERFLOW)?;
> +
> +            io_project!(dma_obj, [try: dma_start..dma_end]).dma_handle()
> +        };
> +
> +        if dma_handle % DmaAddress::from(DMA_LEN) > 0 {
>               dev_err!(
>                   self.dev,
>                   "DMA transfer start addresses must be a multiple of {}\n",
> @@ -533,27 +545,6 @@ fn dma_wr(
>               return Err(EINVAL);
>           }
>   
> -        // DMA transfers can only be done in units of 256 bytes. Compute how many such transfers we
> -        // need to perform.
> -        let num_transfers = load_offsets.len.div_ceil(DMA_LEN);
> -
> -        // Check that the area we are about to transfer is within the bounds of the DMA object.
> -        // Upper limit of transfer is `(num_transfers * DMA_LEN) + load_offsets.src_start`.
> -        match num_transfers
> -            .checked_mul(DMA_LEN)
> -            .and_then(|size| size.checked_add(load_offsets.src_start))
> -        {
> -            None => {
> -                dev_err!(self.dev, "DMA transfer length overflow\n");
> -                return Err(EOVERFLOW);
> -            }
> -            Some(upper_bound) if usize::from_safe_cast(upper_bound) > dma_obj.size() => {
> -                dev_err!(self.dev, "DMA transfer goes beyond range of DMA object\n");
> -                return Err(EINVAL);
> -            }
> -            Some(_) => (),
> -        };
> -
>           // Set up the base source DMA address.
>   
>           self.bar.write(
> @@ -561,12 +552,12 @@ fn dma_wr(
>               regs::NV_PFALCON_FALCON_DMATRFBASE::zeroed().with_base(
>                   // CAST: `as u32` is used on purpose since we do want to strip the upper bits,
>                   // which will be written to `NV_PFALCON_FALCON_DMATRFBASE1`.
> -                (dma_start >> 8) as u32,
> +                (dma_handle >> 8) as u32,

This is a "whaaat?" moment: shifting dma_start makes sense,
but shifting a handle does not.

Thoughts?


thanks,
-- 
John Hubbard


  reply	other threads:[~2026-07-24 18:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 11:10 [PATCH 0/2] gpu: nova-core: falcon: use I/O projections for DMA transfers Alexandre Courbot
2026-07-24 11:10 ` [PATCH 1/2] gpu: nova-core: falcon: remove unnecessary check Alexandre Courbot
2026-07-24 11:10 ` [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds Alexandre Courbot
2026-07-24 18:10   ` John Hubbard [this message]
2026-07-24 22:27     ` Danilo Krummrich
2026-07-25  4:42       ` Alexandre Courbot

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=e7ba2c90-6d4f-487e-bd25-56d568ba1f26@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nova-gpu@lists.linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=ttabi@nvidia.com \
    --cc=zhiw@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox