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/syncobj: add drm_syncobj_fence_lookup Date: Mon, 18 May 2026 16:53:30 +1000 Message-ID: In-Reply-To: <20260516-jorth-syncobj-v1-2-88ede9d98a81@gmail.com> References: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> <20260516-jorth-syncobj-v1-2-88ede9d98a81@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Extracts the core fence-lookup logic from `drm_syncobj_find_fence()`. The split is straightforward. **Issue**: The flags validation (`flags & ~DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT`) is removed from `drm_syncobj_fence_lookup()` but not re-added anywhere except later in patch 5's `drm_syncobj_transfer_ioctl`. This means `drm_syncobj_fence_lookup()` will silently accept unknown flags. The validation should either stay in `drm_syncobj_fence_lookup()` or the commit message should explicitly document why it's being deferred to callers. Looking at the code flow: `drm_syncobj_find_fence()` now calls `drm_syncobj_fence_lookup()` but the flags check happens before the call in `drm_syncobj_find_fence()`: ```c if (flags & ~DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) return -EINVAL; ``` So for the existing `drm_syncobj_find_fence()` callers, the check still applies. The concern is only for direct `drm_syncobj_fence_lookup()` callers -- which only appear in the new code. This is acceptable but the exported function should arguably validate its own inputs. --- Generated by Claude Code Patch Reviewer