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> >
