Re: [PATCH] leds: class: Revert: "If no default trigger is given, make hw_control trigger the default trigger"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 6/12/24 4:58 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Hans, from your point of view, how fast should we try to mainline this
> revert? I got the impression that you want it merged there rather sooner
> than later -- and that sounds appropriate to me.

There are at least 2 separate bug reports from 6.9 users who are gettinhg
stuck tasks which should be fixed by this, so yes this should go upstream
soon.

> So should we maybe ask
> Linus on Friday to pick this up from here? Ideally of course with an ACK
> from Pavel or Lee.

Indeed having an ack from Lee or Pavel here would be great!

Regards,

Hans




> 
> Ciao, Thorsten
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot poke
> 
> On 07.06.24 17:26, Hans de Goede wrote:
>> 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 . 
>> 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>
> 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux