Re: [PATCH] rust: dma: return EOVERFLOW instead of ENOMEM on size overflow

Gary Guo
2026-04-04T13:15:32Z

On Fri Apr 3, 2026 at 10:28 PM BST, Aditya Rajan wrote:
> In alloc_slice_with_attrs(), the checked_mul() guards against
> arithmetic overflow when computing the total byte size
> (size_of::<T>() * len). If this overflows, the current code returns
> ENOMEM, which is misleading -- the system is not out of memory, the
> requested size simply cannot be represented in a usize.
>
> Return EOVERFLOW instead, which accurately describes the failure. This
> also distinguishes it from the actual allocation failure two lines
> below, which correctly returns ENOMEM when dma_alloc_attrs() yields a
> null pointer.
>
> Fixes: d9aee73c56ee ("rust: dma: add generalized container for types other than slices")
> Link: https://lore.kernel.org/all/20260320194626.36263-3-dakr@kernel.org/
>
> Signed-off-by: Aditya Rajan <adi.dev.github@gmail.com>
> ---
> rust/kernel/dma.rs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
> index 4995ee5dc689..179bc8832947 100644
> --- a/rust/kernel/dma.rs
> +++ b/rust/kernel/dma.rs
> @@ -832,7 +832,7 @@ fn alloc_slice_with_attrs(
> Err(EINVAL)?;
> }
>
> - let size = core::mem::size_of::<T>().checked_mul(len).ok_or(ENOMEM)?;
> + let size = core::mem::size_of::<T>().checked_mul(len).ok_or(EOVERFLOW)?;
> let mut dma_handle = 0;
> // SAFETY: Device pointer is guaranteed as valid by the type invariant on `Device`.
> let addr = unsafe {

Hi Aditya,

Thanks for the patch, but the behaviour here is intended.

Neither our `KVec` implementation nor upstream Rust distinguishes between
allocation error caused by array size exceeding address space or running out of
memory to allocate (`AllocError` is returned and it converts to ENOMEM).

`kmalloc_array` also just returns `NULL` when overflows, so arguably this
behaviour also aligns us with C side.

Abstractly, the system is indeed running out memory because it cannot allocate
something larger than its address space.

Best,
Gary