Re: [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds

["Danilo Krummrich" <dakr@kernel.org>]

On Sat Jul 25, 2026 at 6:42 AM CEST, Alexandre Courbot wrote:
> On Sat Jul 25, 2026 at 7:27 AM JST, Danilo Krummrich wrote:
>> On Fri Jul 24, 2026 at 8:10 PM CEST, John Hubbard wrote:
>>> 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.
>>
>> This is inherited from the C API where from its perspective the returned base
>> DMA address of the allocation actually serves as a handle.
>>
>> In Rust the actual handle is represented by different types with different
>> invariants and hence capabilties.
>>
>> (For instance, dma::CoherentBox does not expose the DMA address at all, and
>> hence provides access to its contents through a direct mutable reference,
>> whereas dma::CoherentHandle only provides access to the DMA address and does not
>> have a CPU virtual mapping; dma::Coherent provides access to both.)
>>
>> Both dma::Coherent and dma::CoherentHandle have a dma_handle() method which
>> provides access to the DMA address; this naming was taken over from the C API.
>>
>> Given that the base DMA address serving as a handle from the perspective of the
>> C API is just an implementation detail, we should probably just rename this
>> method to dma_address().
>
> I was also thinking about using `dma_address`, so let's do that!
>
> I guess the pieces required to support a proper DMA range type are also
> starting to fall together.

Yeah, I proposed a dma::Range type a couple of times, but never actually filed
an issue for it. I now added one in [1]; it should also cover getting rid of
dma_handle(), as it would be dma_range() instead. The corresponding address can
be derived from the Range instead.

[1] https://github.com/Rust-for-Linux/linux/issues/1248