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/atomic: Allocate atomic_state at the beginning of atomic_ioctl Date: Tue, 24 Feb 2026 10:27:00 +1000 Message-ID: In-Reply-To: <20260223-atomic-v10-4-f59c8def2e70@intel.com> References: <20260223-atomic-v10-0-f59c8def2e70@intel.com> <20260223-atomic-v10-4-f59c8def2e70@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review > + state = drm_atomic_state_alloc(dev); > + if (!state) > + return -ENOMEM; > + > + drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); > + state->acquire_ctx = &ctx; > + state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET); > + > /* disallow for userspace that has not enabled atomic cap (even Moving the allocation earlier means every ioctl call that fails early validation (bad flags, atomic cap not enabled, etc.) now incurs the overhead of allocating and freeing an atomic state and initializing/finalizing the acquire context. Previously these were cheap early returns. This is a performance regression on common error paths, though probably not significant in practice. The `goto out` cleanup path calls `drm_atomic_state_put(state)` and `drm_modeset_drop_locks(&ctx)` / `drm_modeset_acquire_fini(&ctx)`. I verified that these are safe to call even when no locks were acquired. This is correct. No correctness bugs found here. --- Generated by Claude Code Patch Reviewer