From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f179.google.com (mail-dy1-f179.google.com [74.125.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C63682C21F1 for ; Sat, 4 Apr 2026 17:25:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775323504; cv=none; b=gvginlwgWwajr2mIEh/VhLtMozmpJhJsSUgdvcpJN07YpbGgs3E8Oqu/O+4EntjBequg0WfxnnDLLYdMXqxodWQ1nD7o4vOpb/E7FEFg1VnX82jtfSa4+qRlr+kPOJAI9ffeId1O3Rf2JUzY6Xx8MZ5HxCBz5s/N392ypx0bONE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775323504; c=relaxed/simple; bh=jmB6NcLAsc1+UN+OCM3PMKOU1PmeCf5hHjP+ltB0FgA=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=L1lRZLr3w83wy7EMXtnYOS4fKcnGw8cGsFUnQYdojZFsVnDqtBBhaOK8XIls+zdN0PsZpAEcziR/+LdEXbyrDRaSemEQr76dyMkeA5YPcZqzcdOQn5PwFfrG39EE00Ejy7PTLk86ks7Q7cRcesB8CJv0zu2Q2zjsKvMRkUvlECg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=p5sEU//x; arc=none smtp.client-ip=74.125.82.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="p5sEU//x" Received: by mail-dy1-f179.google.com with SMTP id 5a478bee46e88-2c7d8bbad06so6861775eec.1 for ; Sat, 04 Apr 2026 10:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775323503; x=1775928303; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jmB6NcLAsc1+UN+OCM3PMKOU1PmeCf5hHjP+ltB0FgA=; b=p5sEU//xRG1i6pjmxrx8wqLByK5yxZQZqRIkHC21yq4d7FP0IqLrRYcICWm1OAz7Gu rtnqvTD+FFx5U7BeaSzGUJJAtut9mPu84+1EpcZl2tEjVFtfyeKM/pzbd20BFQUuaE/g rOAwyPIOfgEj4G+UDAUa1RV6cMBfzPhPel6TQoIKE0WZQy3YWSUJFo2R2pqZP0B9Wn79 3T2Xs+kp6BbptQX5dNzuN5cOy/sBPjdV4ZF+SRdl6Yw1C2Tim5lFEYtjkSkszQrJrLQo 96LC/qaa1M0JubqGQNWQ7Y+oS7SYSV70SKuz0pB6gfRdQwjr2TXxDGbcEFx7UtxVYr3Y ZXBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775323503; x=1775928303; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jmB6NcLAsc1+UN+OCM3PMKOU1PmeCf5hHjP+ltB0FgA=; b=lknuWVxyjZ8ZyuWTltGiMsX09miiOaYV/bgTElfeuRC2mJujv52+nUQ52XVOtruJGb 30BCtlE+tOPnWgvmNOQoKug2p1SL6vFGY5T7qHzxPoB4wEomm5vIPip21lv/5odaUUyk 0orGOoTcfgjepYXl0LvcmcA/nczTW6rPY4knU9GCFHUgjvuwDM/ViuYh64NtdqfY3QGe NdJXmUEmcmejS7zBdKyoakoHGYas8l7pIhPacr51j8sossfrOQdeX2SYK2Oa6RD/9tag sPGwVVspjSQL9DSoxrSsQshMOrp2pzZ3lxL/iEdg+WfvhmTItME35igp5AndvIyKFYeN bfzg== X-Forwarded-Encrypted: i=1; AJvYcCX9ib4FSFB1u8BL8dOY45QfDfQx/buUdVH5I7F9CEJO2yArR19maBeaSnkMdBS1Axv1dgjF4DQu5k58Kto=@vger.kernel.org X-Gm-Message-State: AOJu0Yxv/RJrownLMgXD+9S815V+wD4CEZb+3WB2iD0pfwUXIcXJbNIs 3u+z0N79b9Xh//FsZKLUDM3XTzrScA7PYSCn22ae8ZZWJH5DkPuTYk6x6auTjQ== X-Gm-Gg: AeBDietykM+hskE7Uo7IPFnLKwzZd07e0q0S2OLPoZC8RYc+yZo6CHYpe0PukXifo00 ER8AtX5kxRd7f6c3UfMG/R4wmWNcmmFa5AURZlBF1Aw64Y3pHDakNfxFj1z8ANUdweUBubKQ6oR yuI4fByf5dkBs5ZOBJuBikLbWKOtaeWUOaA7KxLgVJ3JWJa8Falf1BIvKgsN2dlnAW3GEto8nck Fm31wWK8RcxLCjklMGa3iR2MHTwYBNLNSGY9xJceB/EpF7v7xsIxXdhjib6da/Pespinx/Hsiqv y2jwuVMz67xgsZd4+BSq7k1htUTzFoUiG6EP9TA+5iF/ubU5Kuihx12d1k2UAHwfQGJbs/lXLuq htUSLKJCmFYhY4owYuERIo30at3smRaWflaC6x48bpmfxwHOgxKJmeuS72dr2EzhCPOCa2cyVIu D3RrvTSlKxz+CjsXOuRKSGMPQAzY02iyv+UJ5HA2aUhKyX0zjw5HaHf3cTeTZJng== X-Received: by 2002:a05:7300:641a:b0:2be:8216:57db with SMTP id 5a478bee46e88-2cbf99ec1bdmr3767503eec.3.1775323502804; Sat, 04 Apr 2026 10:25:02 -0700 (PDT) Received: from localhost ([2603:8000:bb00:9b3f:5094:4d4:5bc0:f9f9]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2ca793eecd1sm8003832eec.10.2026.04.04.10.25.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Apr 2026 10:25:02 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 04 Apr 2026 10:24:59 -0700 Message-Id: Cc: , , , , , , , , , , , Subject: Re: [PATCH] rust: dma: return EOVERFLOW instead of ENOMEM on size overflow From: "Aditya Rajan" To: "Gary Guo" , "Aditya Rajan" , , X-Mailer: aerc 0.21.0 References: <20260403212822.294288-1-adi.dev.github@gmail.com> In-Reply-To: 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 all= ocate > 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, &by= tes)` and returns ERR_PTR(-EOVERFLOW), it is kind of same multiplication ov= erflow on `nmemb*size` before an allocation. Similarly `mm/mmap.c` returns = EOVERFLOW for arithmetic overflow in offset calculations, it also has a com= ment `/* 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(EOVER= FLOW)?` for the same kind of arithmetic overflow check. * For `kmalloc_array` i think it conflates overflow with OOM because its re= turn type (pointer) can't express distinct errors, maybe it should be impro= ved 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 call= er into retrying a request that can never succeed. Thanks, Aditya