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

["Gary Guo" <gary@garyguo.net>]

On Sat Apr 4, 2026 at 6:24 PM BST, Aditya Rajan wrote:
> 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? */`.

I think these cases are all related to values ultimately controlled by
userspace, and the error conditions are propagated back to userspace, so it
makes more sense to distinguish errors.

On the other hand, for KVec/Coherent cases, it is less useful to distinguish
between the cases. If we want to add EOVERFLOW, then we'd need to extend
AllocError to have two enums, which I wouldn't be against, but I think it's not
worth having.

(I wanted Coherent to use AllocError as error too, but as it does not support
zero-size allocation, so I didn't change the error type. I guess one option is
to handle zero-size case by using a dangling pointer similar to `KVec`.)

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

If I allocate `usize::MAX`, it'll never work but the error would still be
ENOMEM, and I see no reason to differentiate `usize::MAX` and `usize::MAX + 1`.

Best,
Gary