Hi Andrew,
On 6/7/24 2:03 PM, Andrew Lunn wrote:
> On Fri, Jun 07, 2024 at 12:18:47PM +0200, Hans de Goede wrote:
>> Commit 66601a29bb23 ("leds: class: If no default trigger is given, make
>> hw_control trigger the default trigger") causes ledtrig-netdev to get
>> set as default trigger on various network LEDs.
>>
>> This causes users to hit a pre-existing AB-BA deadlock issue in
>> ledtrig-netdev between the LED-trigger locks and the rtnl mutex,
>> resulting in hung tasks in kernels >= 6.9.
>>
>> Solving the deadlock is non trivial, so for now revert the change to
>> set the hw_control trigger as default trigger, so that ledtrig-netdev
>> no longer gets activated automatically for various network LEDs.
>>
>> The netdev trigger is not needed because the network LEDs are usually under
>> hw-control and the netdev trigger tries to leave things that way so setting
>> it as the active trigger for the LED class device is a no-op.
>>
>> Fixes: 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger")
>> Reported-by: Genes Lists <lists@xxxxxxxxxxxx>
>> Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@xxxxxxxxxxxx/
>> Reported-by: "Johannes Wüller" <johanneswueller@xxxxxxxxx>
>> Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@xxxxxxxxx/
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>
> I'm not sure i agree with the Closes: All this does is make it less
> likely to deadlock. The deadlock is still there.
I agree that the deadlock which is the root-cause is still there. But
with this revert ledtrig-netdev will no longer get activated by default.
So now the only way to actually get the code-paths which may deadlock
to run is by the user or some script explicitly activating the netdev
trigger by writing "netdev" to the trigger sysfs file for a LED classdev.
So most users will now no longer hit this, including the reporters of
these bugs.
The auto-activating of the netdev trigger is what is causing these
reports when users are running kernels >= 6.9 .
> But:
>
> Reviewed-by: Andrew Lunn <andrew@xxxxxxx>
Thank you.
Regards,
Hans
