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: protect bridge private_obj during bridge removal Date: Wed, 25 Mar 2026 06:50:56 +1000 Message-ID: In-Reply-To: <20260324-drm-bridge-atomic-vs-remove-private_obj-v3-0-64deefe84044@bootlin.com> References: <20260324-drm-bridge-atomic-vs-remove-private_obj-v3-0-64deefe84044@bootlin.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: drm/atomic: protect bridge private_obj during bridge removal Author: Luca Ceresoli Patches: 2 Reviewed: 2026-03-25T06:50:56.340536 --- This is a single-patch series addressing a real race condition in DRM bridge hot-unplug. The problem is well-understood and clearly documented in the commit message: when a bridge's `private_obj` is being finalized via `drm_bridge_detach()` concurrently with code that holds modeset locks (e.g., `drm_mode_obj_get_properties_ioctl()` using `DRM_MODESET_LOCK_ALL_BEGIN/END`), the `drm_modeset_lock_fini()` call hits a `WARN_ON` because the lock is still on the acquire context's locked list. The fix is minimal and correct: wrap the `list_del(&obj->head)` in `drm_atomic_private_obj_fini()` with `DRM_MODESET_LOCK_ALL_BEGIN/END`. This serializes the list removal against concurrent lock acquisition, ensuring the private object is either fully locked by the concurrent user (who will finish and release before fini proceeds) or removed from the list before the concurrent user iterates it. The series is well-motivated as part of ongoing DRM bridge hotplug work, and the roadmap in the cover letter is appreciated. --- Generated by Claude Code Patch Reviewer