Messages in this thread | | | From | Ben Hutchings <> | Date | Wed, 20 Apr 2011 05:48:30 +0100 | Subject | Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround |
| |
On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote: > On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote: > > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote: > > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote: > > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote: > > > > > 2.6.32-longterm review patch. If anyone has any objections, please let us know. > > > > > > > > > > ------------------ > > > > > > > > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com> > > > > > > > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream. > > > > > > > > > > Remove check_c1e_idle() and use the new AMD errata checking framework > > > > > instead. > > > > > > > > Clean-up patches are generally not candidates for longterm updates. > > > > > > This was added because a follow-on patch required it. > > > > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same > > condition. > > > > Of course, that could have been backported by referring to the function > > that this removes, rather than pulling in a load of other changes with > > consequent risk of regressions. > > I prefer to take original patches for stable, it makes it easier in the > end.
It makes what easier, when? What I see here is a bug fix that is much larger than necessary, with a consequent risk of regression that seems way out of proportion to the benefit. (What actually *is* the benefit of these AMD changes?) And we have had several serious regressions in the 2.6.32.y series recently, so I really don't think we are getting the trade-off right.
Ben.
-- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. [unhandled content-type:application/pgp-signature] | |