From: Tomer Tayar tomer.tayar@intel.com
[ Upstream commit 9f5067531c9b79318c4e48a933cb2694f53f3de2 ]
EFAULT is currently returned if less than requested user pages are pinned. This value means a "bad address" which might be confusing to the user, as the address of the given user memory is not necessarily "bad".
Modify the return value to ENOMEM, as "out of memory" is more suitable in this case.
Signed-off-by: Tomer Tayar tomer.tayar@intel.com Reviewed-by: Koby Elbaz koby.elbaz@intel.com Signed-off-by: Koby Elbaz koby.elbaz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - The change only adjusts the fallback errno when `pin_user_pages_fast()` pins fewer pages than requested, switching from `-EFAULT` to `-ENOMEM` in `get_user_memory()` (`drivers/accel/habanalabs/common/memory.c:2333`, `drivers/accel/habanalabs/common/memory.c:2340`). That path feeds directly into the user-visible `hl_pin_host_memory()` ioctl stack, so the errno returned to userspace shifts with no other behavioral differences. - A shortfall from `pin_user_pages_fast()` is typically triggered by resource exhaustion (memlock limits, long-term pinning restrictions, or temporary faults) rather than an invalid pointer. GUP’s core comment and return path (`mm/gup.c:1324`, `mm/gup.c:1509`) document that it returns the number of pages successfully pinned even when the underlying failure was `-ENOMEM`/`-EAGAIN`/`-EFAULT`, so callers lose the real error code once any pages were pinned. Treating the condition as out-of-resources better matches the dominant failure mode and mirrors what other subsystems do (e.g. the VDUSE bounce buffer path uses the same fallback to `-ENOMEM`, `drivers/vdpa/vdpa_user/vduse_dev.c:1116`). - Leaving it as `-EFAULT` misdirects userspace into believing the address is invalid, which can mask real memory-pressure problems and complicate recovery. The driver already logs a detailed error, so the only user-visible change is a more accurate errno for a genuine failure case. - Regression risk is negligible: no control flow moved, and no in-kernel caller special-cases the old errno. The edit is self-contained and stable-friendly; older trees only need the path adjusted back to `drivers/misc/habanalabs/common/memory.c`. - Recommended next steps: if you pull this into stable, queue a quick smoke test of the habanalabs memory-pinning ioctl to confirm expected errno propagation under memlock exhaustion.
drivers/accel/habanalabs/common/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/common/memory.c b/drivers/accel/habanalabs/common/memory.c index 61472a381904e..48d2d598a3876 100644 --- a/drivers/accel/habanalabs/common/memory.c +++ b/drivers/accel/habanalabs/common/memory.c @@ -2332,7 +2332,7 @@ static int get_user_memory(struct hl_device *hdev, u64 addr, u64 size, if (rc < 0) goto destroy_pages; npages = rc; - rc = -EFAULT; + rc = -ENOMEM; goto put_pages; } userptr->npages = npages;