Claude review: drm/atomic: protect bridge private_obj during bridge removal

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

Patch Review

**Correctness**: The fix is correct. Looking at `drm_modeset_lock_all_ctx()` (in `drm_modeset_lock.c:451`), it iterates `drm_for_each_privobj()` and locks each private object. The race occurs when CPU1 calls `drm_atomic_private_obj_fini()` and does `list_del(&obj->head)` + `drm_modeset_lock_fini(&obj->lock)` while CPU0 still holds that lock in its acquire context. By wrapping `list_del` with `DRM_MODESET_LOCK_ALL_BEGIN/END`, the fini path must first acquire all modeset locks, which serializes against any concurrent `drm_modeset_lock_all_ctx()` user.

**One subtlety worth considering**: After `DRM_MODESET_LOCK_ALL_BEGIN` acquires all locks, it will also lock `obj->lock` itself (since `obj` is still in the `privobj_list` at that point). The `DRM_MODESET_LOCK_ALL_END` then drops all locks including `obj->lock`. Then `drm_modeset_lock_fini(&obj->lock)` is called outside the locked section, which checks `WARN_ON(!list_empty(&lock->head))` — at this point `lock->head` has been removed from `ctx->locked` by `drm_modeset_drop_locks()`, so the warn won't trigger. This is correct.

**Potential concern — `obj->dev` being NULL or stale**: The function uses `obj->dev` which was added by a prior patch ("drm/atomic: Add dev pointer to drm_private_obj"). This is fine as long as `obj->dev` is set during `drm_atomic_private_obj_init()` (confirmed at line 943: `obj->dev = dev;`).

**Ordering of operations**: The `atomic_destroy_state()` and `drm_modeset_lock_fini()` remain outside the locked region, which is correct — once the object is removed from the list, no concurrent code can find it, so no locking is needed for teardown.

**Minor nit**: The commit message says "Prevent this potential deadlock" but the issue described is actually a warning/use-after-remove, not a deadlock per se. The `DRM_MODESET_LOCK_ALL_BEGIN/END` approach handles actual deadlocks (via `-EDEADLK` backoff), but the original problem being solved is a race, not a deadlock. The v3 changelog mentions "Small commit message clarification" but this wording persists. Very minor.

**Overall**: Clean, minimal, correct fix. The approach of serializing via `DRM_MODESET_LOCK_ALL_BEGIN/END` is the right one — it reuses the existing deadlock avoidance infrastructure (ww_mutex) rather than introducing a new lock.

Reviewed-by worthy.

---
Generated by Claude Code Patch Reviewer