On Mon Sep 21, 2026 at 9:16 AM CEST, Luca Ceresoli wrote: > Hello Cristian, > > On Tue Sep 1, 2026 at 8:50 PM CEST, Cristian Ciocaltea wrote: >> When re-adding a bridge that was previously removed, drm_bridge_add() >> drops it from bridge_lingering_list without holding bridge_lock. >> >> Both bridge_list and bridge_lingering_list are protected by bridge_lock, >> as they are concurrently modified by drm_bridge_remove() and >> __drm_bridge_free(), and walked by the debugfs 'bridges' file. Running >> the list_empty() test and the list_del_init() outside of the lock may >> therefore corrupt either list. > > The analysis appears correct, with a small nit: __drm_bridge_free() cannot > touch the list concurrently to other functions, because it only runs when > the refcount is 0, and all other functions tounch the lists only when they > have a reference. (Should this sentence be wrong, that would be a big bug!)
Ah, no, I just realized my concern does not stand. Indeed __drm_bridge_free() can run concurrently on a different bridge than the one being handled by other functions, ending up in modifying the same list. So your comment is fully correct: Reviewed-by: Luca Ceresoli <[email protected]> Apologies for the noise. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
