From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: accel/habanalabs: reject zero-element timestamp buffer allocation Date: Sat, 14 Feb 2026 07:24:29 +1000 Message-ID: In-Reply-To: <20260213173530.2963318-1-n7l8m4@u.northwestern.edu> References: <20260213173530.2963318-1-n7l8m4@u.northwestern.edu> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: accel/habanalabs: reject zero-element timestamp buffer allocation Author: Ziyi Guo Patches: 1 Reviewed: 2026-02-14T07:24:29.658724 --- This is a single-patch submission that adds a zero-element check to the times= tamp buffer allocation path in the habanalabs (accel) driver. The fix address= es a real issue: a userspace caller can pass `num_of_elements=3D0` via the `D= RM_IOCTL_HL_MEMORY` ioctl with `op=3DHL_MEM_OP_TS_ALLOC`, which flows uncheck= ed into `vmalloc_user(0)` and triggers a `WARN_ON_ONCE(!size)` in `__vmalloc_= node_range()`. On `panic_on_warn=3D1` systems, this is a local denial-of-serv= ice. The fix is straightforward and correct. The approach =E2=80=94 extending the = existing upper-bound check to also reject zero =E2=80=94 is the right thing t= o do. The commit message is well-written, explains the root cause clearly, re= ferences the matching pattern at `HL_MEM_OP_ALLOC`, and includes an appropria= te Fixes tag. No significant issues found. --- Generated by Claude Code Patch Reviewer