From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: misc/syncobj: add /dev/syncobj device Date: Mon, 18 May 2026 16:53:29 +1000 Message-ID: In-Reply-To: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> References: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Overall Series Review Subject: misc/syncobj: add /dev/syncobj device Author: Julian Orth Patches: 16 Reviewed: 2026-05-18T16:53:29.890629 --- This 12-patch series by Julian Orth introduces `/dev/syncobj`, a standalone misc device that exposes DRM syncobj operations without requiring a DRM device node. The motivation is sound: Wayland compositors and software renderers (llvmpipe) need syncobj interop for buffer synchronization but currently must open a DRM device node even when no GPU-specific logic is involved. The series is well-structured: patches 1-11 refactor the existing `drm_syncobj.c` code to extract reusable building blocks that accept `struct drm_syncobj *` directly rather than `drm_file`/handle pairs. Patch 12 then builds the new `/dev/syncobj` misc device on top. The refactoring is generally clean and incremental. **Key concerns:** 1. **Architectural placement**: The author themselves flags this -- `drivers/misc/` is questionable for something tightly coupled to the DRM subsystem. This probably belongs under `drivers/gpu/drm/` or at least should get buy-in from Greg KH on the misc placement. 2. **`copy_from_user` in exported helper**: `drm_syncobj_timeline_signal()` and `drm_syncobj_query()` take raw `u64 user_points` and internally call `copy_from_user`. This is an unusual and problematic API design for a kernel-internal exported function -- callers outside the DRM ioctl path shouldn't need to deal with user pointers at that abstraction level. 3. **ioctl number conflict**: `0xCD` is claimed as dead (reiserfs, removed in 6.13), but the new allocation `0xCD 00-0F` overlaps with the existing `0xCD 01` reservation line. This needs formal ioctl allocation review. 4. **The bug fix in patch 9 is real** and should be sent separately as a standalone fix with a Fixes: tag targeting the commit that introduced the `point` parameter support. 5. **No selftests** are included for the new device. A `kselftest` for the new ioctls would significantly strengthen the submission. 6. **No documentation** beyond the ioctl-number.rst entry. A doc file describing the new userspace API semantics would be valuable. Overall: the idea has clear merit for the Wayland ecosystem, but the internal API design (user pointers in exported functions) needs rework, and the series needs tests and documentation. --- --- Generated by Claude Code Patch Reviewer