On Fri, Nov 06, 2020 at 08:27:44PM +0000, Vineet Gupta wrote: > Hi Stable Team, > > On 10/19/20 7:19 PM, Vineet Gupta wrote: > > This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729. > > (but only from 5.2 and prior kernels) > > > > The original commit was a preventive fix based on code-review and was > > auto-picked for stable back-port (for better or worse). > > It was OK for v5.3+ kernels, but turned up needing an implicit change > > 68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have > > exception cause)" merged in v5.3 which itself was not backported. > > So to summarize the stable backport of this patch for v5.2 and prior > > kernels is busted and it won't boot. > > > > The obvious solution is backport 68e5c6f073bcf70 but that is a pain as > > it doesn't revert cleanly and each of affected kernels (so far v4.19, > > v4.14, v4.9, v4.4) needs a slightly different massaged varaint. > > So the easier fix is to simply revert the backport from 5.2 and prior. > > The issue was not a big deal as it would cause strace to sporadically > > not work correctly. > > > > Waldemar Brodkorb first reported this when running ARC uClibc regressions > > on latest stable kernels (with offending backport). Once he bisected it, > > the analysis was trivial, so thx to him for this. > > > > Reported-by: Waldemar Brodkorb <wbx@xxxxxxxxxxxxx> > > Bisected-by: Waldemar Brodkorb <wbx@xxxxxxxxxxxxx> > > Cc: stable <stable@xxxxxxxxxxxxxxx> # 5.2 and prior > > Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx> > > Can this revert be please applied to 4.19 and older kernels for the next cycle. > > Or is there is a procedural issue given this revert is not in mainline. I've > described the issue in detail above so if there's a better/desirable way of > reverting it from backports, please let me know. THis is fine, sorry, it's just in a backlog of lots of stable patches... We will get to it soon. thanks, greg k-h
