From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/virtgpu: Use ERR_PTR for fb_create callback error return Date: Fri, 05 Jun 2026 06:40:48 +1000 Message-ID: In-Reply-To: <20260604071202.138235-1-liuqiangneo@163.com> References: <20260604071202.138235-1-liuqiangneo@163.com> <20260604071202.138235-1-liuqiangneo@163.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Correctness: Good.** The `fb_create` callback's return contract is docume= nted in `include/drm/drm_mode_config.h:78-81`: > RETURNS: A new framebuffer with an initial reference count of 1 or a nega= tive error code encoded with ERR_PTR(). The caller in the DRM core will use `IS_ERR()` to check the return value. R= eturning `NULL` instead of `ERR_PTR()` means the caller would not detect th= e error =E2=80=94 it would treat `NULL` as a valid framebuffer pointer, lea= ding to a null pointer dereference. **Consistency: Good.** Looking at the patched function (`virtgpu_display.c:= 318-351`), the three other error paths in `virtio_gpu_user_framebuffer_crea= te` already return `ERR_PTR()` correctly: ```c return ERR_PTR(-ENOENT); // line 330 - bad pixel format return ERR_PTR(-EINVAL); // line 335 - object lookup failure return ERR_PTR(-ENOMEM); // line 340 - allocation failure ``` Only the `virtio_gpu_framebuffer_init` failure path (the one being fixed) w= as inconsistent, returning `NULL`. The fix changes it to `ERR_PTR(ret)`, wh= ich correctly propagates the actual error code from `virtio_gpu_framebuffer= _init`. **No issues found.** Clean, minimal, correct fix. --- Generated by Claude Code Patch Reviewer