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/bridge: lock the encoder chain in scoped for_each loops Date: Wed, 25 Mar 2026 06:59:31 +1000 Message-ID: In-Reply-To: <20260324-drm-bridge-alloc-encoder-chain-mutex-v5-4-8bf786c5c7e6@bootlin.com> References: <20260324-drm-bridge-alloc-encoder-chain-mutex-v5-0-8bf786c5c7e6@bootlin.com> <20260324-drm-bridge-alloc-encoder-chain-mutex-v5-4-8bf786c5c7e6@bootlin.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review This is the most complex patch. The mutex lifecycle in the for_each macros = is well-designed: **`__drm_for_each_bridge_in_chain_next()`**: Gets the next bridge (incremen= ting its refcount), then conditionally unlocks the mutex only when we've re= ached the end of the chain (`!next`), then puts the current bridge. The ord= ering is correct =E2=80=94 the next bridge's refcount is incremented before= the current bridge is released. **`__drm_for_each_bridge_in_chain_cleanup`**: Called via `__free()` when th= e loop variable goes out of scope (break/return). Correctly checks `if (_T)= ` to handle the normal loop-completion case where `_T` is already NULL (mut= ex was already unlocked in `_next()`). **`__drm_for_each_bridge_in_chain_scoped_start()`**: Locks mutex, gets firs= t bridge, unlocks if no bridges exist. This avoids leaving the mutex locked= when there's nothing to iterate. **Potential concern:** In `__drm_for_each_bridge_in_chain_from_start()`, th= e bridge is `drm_bridge_get()`'d before the mutex is locked. If the bridge = is being concurrently removed from the chain (before the mutex is taken), t= he bridge struct remains valid due to the refcount, but its `chain_node` li= nks could be poisoned. Since `drm_bridge_detach()` calls `list_del()` which= sets the pointers to `LIST_POISON`, this could be problematic. However, th= e refcount prevents the bridge from being freed, and the mutex prevents con= current chain modifications during actual iteration. The brief window betwe= en `drm_bridge_get()` and `mutex_lock()` should be safe because the caller = is expected to already hold a reference to `first_bridge`. No blocking issues. --- Generated by Claude Code Patch Reviewer