On Mon Sep 21, 2026 at 9:21 AM CEST, Luca Ceresoli wrote: > 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]>
And tested with bridge hotplug: Tested-by: Luca Ceresoli <[email protected]> -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
