On 2025-01-30 15:00:35+0100, Hans de Goede wrote:
> Since commit 6037802bbae8 ("power: supply: core: implement extension API")
> there is the following ABBA deadlock (simplified) between the LED trigger
> code and the power-supply code:
>
> 1) When registering a power-supply class device, power_supply_register()
> calls led_trigger_register() from power_supply_create_triggers() in
> a scoped_guard(rwsem_read, &psy->extensions_sem) context.
> led_trigger_register() then in turn takes a LED subsystem lock.
> So here we have the following locking order:
>
> * Read-lock extensions_sem
> * Lock LED subsystem lock(s)
>
> 2) When registering a LED class device, with its default trigger set
> to a power-supply LED trigger (which has already been registered)
> The LED class code calls power_supply_led_trigger_activate() when
> setting up the default trigger. power_supply_led_trigger_activate()
> calls power_supply_get_property() to determine the initial value of
> to assign to the LED and that read-locks extensions_sem. So now we
> have the following locking order:
>
> * Lock LED subsystem lock(s)
> * Read-lock extensions_sem
>
> Fixing this is easy, there is no need to hold the extensions_sem when
> calling power_supply_create_triggers() since all triggers are always
> created rather then checking for the presence of certain attributes as
> power_supply_add_hwmon_sysfs() does. Move power_supply_create_triggers()
> out of the guard block to fix this.
<snip>
> Fixes: 6037802bbae8 ("power: supply: core: implement extension API")
> Cc: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
> Cc: Armin Wolf <W_Armin@xxxxxx>
> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
Thanks!
Reviewed-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
