On 11.05.23 21:51, Limonciello, Mario wrote: > [AMD Official Use Only - General] > > +stable, Sasha > >>> Together with this patch there are now at least two regressions if >>> -rc1 whch could have been avoided and may impact testability on >>> affected systems. >> >> Are you saying that this patch which fixes s2idle on some random box >> should've gone to Linus *immediately*? >> >> And read my mail again: >> >> "Some fixes need longer testing because there have been cases where >> a fix breaks something else." >> >> So yes, I disagree with rushing fixes immediately. If they're obvious >> - whatever that means - then sure but not all of them are such. >> >> -- > > Unfortunately, it looks like the broken commit got backported into 6.1.28, > but the fix still isn't in Linus' tree. > > Sasha, > > Can you please pick up > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=23a5b8bb022c1e071ca91b1a9c10f0ad6a0966e9 > for 6.1.29 to fix the regression? FWIW, the stable team afaics usually does not fix anything in stable trees before it's fixed in mainline. IOW: that fix now quickly needs to go to Linus to get it quickly fixed in 6.1.y. Side note: I'll soon post a rewritten section of 'Prioritize work on fixing regressions' which is part of Documentation/process/handling-regressions.rst. It among others will cover this case: ``` * Whenever you want to swiftly resolve a regression that recently also made it into a proper mainline, stable, or longterm release, fix it quickly in mainline; when appropriate thus involve Linus to fast-track the fix. That's because the stable team normally does neither revert nor fix any changes that cause a regression in mainline, too. ``` Ciao, Thorsten
