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

[Aditya Rajan]

On Sat Apr 4, 2026 at 6:15 AM PDT, Gary Guo wrote:

> 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.

Hi Gary,

Thanks for the reply, I saw at some similar places where EOVERFLOW is used, that is why i thought we should change this error code:

* In nouveau_drv.h, `u_memcpya()` does `check_mul_overflow(nmemb, size, &bytes)` and returns ERR_PTR(-EOVERFLOW), it is kind of same multiplication overflow on `nmemb*size` before an allocation. Similarly `mm/mmap.c` returns EOVERFLOW for arithmetic overflow in offset calculations, it also has a comment `/* offset overflow? */`.

* Also I saw existing Rust kernel code already follows similar convention, see `rust/kernel/uaccess.rs` it uses `offset.checked_add(count).ok_or(EOVERFLOW)?` for the same kind of arithmetic overflow check.

* For `kmalloc_array` i think it conflates overflow with OOM because its return type (pointer) can't express distinct errors, maybe it should be improved as well ?. When the API can distinguish (like here, or in nouveau), the kernel does use (or maybe should use?) `EOVERFLOW`.

IMO two failures have different semantics for callers, ENOMEM is transient (retry may succeed under less memory pressure), EOVERFLOW is deterministic (the input will never work). Using ENOMEM for overflow could mislead a caller into retrying a request that can never succeed.

Thanks, Aditya