Claude review: misc/syncobj: add /dev/syncobj device

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

Overall Series Review

Subject: misc/syncobj: add /dev/syncobj device
Author: Julian Orth <ju.orth@gmail.com>
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