From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/atomic: Return user readable error in atomic_ioctl
Date: Tue, 24 Feb 2026 10:27:00 +1000 [thread overview]
Message-ID: <review-patch5-20260223-atomic-v10-5-f59c8def2e70@intel.com> (raw)
In-Reply-To: <20260223-atomic-v10-5-f59c8def2e70@intel.com>
Patch Review
This is the main functional patch and has several issues.
> + if (!arg->reserved)
> + drm_dbg_atomic(dev,
> + "memory not allocated for drm_atomic error reporting\n");
> + else
> + /* Update the error code if any error to allow user handling it */
> + error_code_ptr = (struct drm_mode_atomic_err_code __user *)
> + (unsigned long)arg->reserved;
Emitting a debug message every time userspace does NOT opt into error reporting seems backwards. Most userspace (including all existing userspace) will not set `reserved`, so this will spam the debug log on every successful atomic ioctl call. This debug message should be removed.
> + memset(&state->error_code, 0, sizeof(*error_code_ptr));
When `arg->reserved` is 0, `error_code_ptr` is uninitialized. Using `sizeof(*error_code_ptr)` works because `sizeof` is evaluated at compile time, but this is confusing. It should be `sizeof(state->error_code)` for clarity.
> + if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS) {
> + drm_mode_atomic_add_error_msg(&state->error_code,
> + DRM_MODE_ATOMIC_INVALID_API_USAGE,
> + "invalid flag");
> ret = -EINVAL;
> goto out;
> }
The patch removes the `drm_dbg_atomic` call for the invalid flags case, replacing it solely with the error_msg function. But `drm_mode_atomic_add_error_msg` calls `drm_dbg_atomic` internally, so the debug output is preserved. This is fine, though the other error paths (e.g., "atomic cap not enabled") keep both the explicit `drm_dbg_atomic` AND the error_msg call, which results in double debug output for those paths. The approach should be consistent.
> - if (arg->reserved) {
> - drm_dbg_atomic(dev, "commit failed: reserved field set\n");
> - ret = -EINVAL;
> - goto out;
> - }
The `reserved` field validation is removed because the field is now repurposed. This relies on old userspace always passing 0 in `reserved`. Since the old kernel rejected non-zero values, well-behaved userspace should indeed pass 0. However, the safer pattern used elsewhere in DRM is to add a new flag to opt into the new behavior, rather than silently reinterpreting a previously-validated field.
> +out:
> + /* Update the error code if any error to allow user handling it */
> + if (ret < 0 && arg->reserved) {
> + if (copy_to_user(error_code_ptr, &state->error_code,
> + sizeof(state->error_code)))
> + ret = -EFAULT;
> + }
This runs on the `-EDEADLK` path before the deadlock recovery check. If `copy_to_user` fails (e.g., the user pointer is invalid), `ret` is changed to `-EFAULT`, and the `ret == -EDEADLK` check below will be false. This means a bad error pointer will **prevent deadlock recovery**, turning a transient retry into a permanent failure. The `copy_to_user` should be skipped for `-EDEADLK`, or the EDEADLK check should be moved before the copy_to_user.
Also, on the `-EDEADLK` retry path, this writes potentially-stale error data to userspace (from a failed attempt that will be retried). The retry might succeed, but userspace has already received error data.
> + if (ret) {
> + drm_mode_atomic_add_error_msg(&state->error_code,
> + DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED,
> + "property change not allowed in async flip");
> + }
In `drm_atomic_set_property`, the error message is added for connector and crtc async property changes. But looking at the code flow, the `drm_atomic_check_prop_changes` call is made only inside the `if (async_flip)` block. The error message should include which property or object triggered it, similar to how the plane case includes `obj->id` and `plane->name`.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-02-24 0:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 9:15 [PATCH v10 0/7] User readable error codes on atomic_ioctl failure Arun R Murthy
2026-02-23 9:15 ` [PATCH v10 1/7] drm: Define user readable error codes for atomic ioctl Arun R Murthy
2026-02-24 0:26 ` Claude review: " Claude Code Review Bot
2026-02-23 9:16 ` [PATCH v10 2/7] drm/atomic: Add error_code element in atomic_state Arun R Murthy
2026-02-24 0:26 ` Claude review: " Claude Code Review Bot
2026-02-23 9:16 ` [PATCH v10 3/7] drm/atomic: Call complete_signaling only if prepare_signaling is done Arun R Murthy
2026-02-24 0:26 ` Claude review: " Claude Code Review Bot
2026-02-23 9:16 ` [PATCH v10 4/7] drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl Arun R Murthy
2026-02-24 0:27 ` Claude review: " Claude Code Review Bot
2026-02-23 9:16 ` [PATCH v10 5/7] drm/atomic: Return user readable error in atomic_ioctl Arun R Murthy
2026-02-24 0:27 ` Claude Code Review Bot [this message]
2026-02-23 9:16 ` [PATCH v10 6/7] drm/i915/display: Error codes for async flip failures Arun R Murthy
2026-02-24 0:27 ` Claude review: " Claude Code Review Bot
2026-02-23 9:16 ` [PATCH v10 7/7] drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING Arun R Murthy
2026-02-24 0:27 ` Claude review: " Claude Code Review Bot
2026-02-23 10:07 ` [PATCH v10 0/7] User readable error codes on atomic_ioctl failure Murthy, Arun R
2026-02-24 0:26 ` Claude review: " Claude Code Review Bot
-- strict thread matches above, loose matches on Subject: below --
2026-02-10 9:03 [PATCH v9 0/7] " Arun R Murthy
2026-02-10 9:03 ` [PATCH v9 5/7] drm/atomic: Return user readable error in atomic_ioctl Arun R Murthy
2026-02-11 6:31 ` Claude review: " Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch5-20260223-atomic-v10-5-f59c8def2e70@intel.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox