Claude review: User readable error codes on atomic_ioctl failure

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: User readable error codes on atomic_ioctl failure
Author: Arun R Murthy <arun.r.murthy@intel.com>
Patches: 9
Reviewed: 2026-02-24T10:26:59.069405

---

This series adds user-readable error codes to the DRM atomic ioctl by repurposing the `reserved` field of `struct drm_mode_atomic` as a pointer to a new `struct drm_mode_atomic_err_code`. When the atomic ioctl fails, the kernel populates this struct with an error code enum and a human-readable error string, then copies it back to userspace. A new capability `DRM_CAP_ATOMIC_ERROR_REPORTING` is added so userspace can discover support.

The idea of providing richer error information from atomic commits has value, particularly for compositor developers debugging modeset failures. However, the implementation has several significant issues that need to be addressed before this can be merged.

The most critical bug is a **memory leak** in `drm_mode_atomic_add_error_msg`: `kvasprintf()` allocates a string that is never freed. This leaks memory on every error path. There is also a **NULL pointer dereference** if that allocation fails. Beyond that, the UAPI design has problems: the failure code enum starts at 0, making it impossible for userspace to distinguish "no error was reported" from `DRM_MODE_ATOMIC_INVALID_API_USAGE`. The `copy_to_user` on the `-EDEADLK` retry path can abort deadlock recovery if the user pointer is bad. Several fields in the new UAPI struct (`failure_objs_ptr`, `count_objs`, `reserved`) are never populated by any patch. The cover letter still contains "EDITME" placeholders, and the kernel-doc has multiple typos. The capability in patch 7 reports error reporting as supported for all atomic drivers, even though only i915 populates any error codes.

---
Generated by Claude Code Patch Reviewer