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

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

On Sat Apr 4, 2026 at 10:13 PM CEST, Gary Guo wrote:
> 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.

That's not the main difference, any of those primitives may be called on behalf
of userspace with the error propagated back to userspace. Please also see my
considerations in [1].

[1] https://lore.kernel.org/lkml/DHKMLRW67JB9.2VGA6EGTLYSCU@kernel.org/

> 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'd rather not, let's keep it consistent with other memory allocation
primitives.

> (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`.)

I'm against this, a zero-sized dma::Coherent allocation does not make sense; I'd
really want to see a real use-case for this.

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

Agreed.