linux-kernel - Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Apr 2011 22:06:17 -0700
From:	Greg KH <gregkh@...e.de>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Hans Rosenfeld <hans.rosenfeld@....com>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	akpm@...ux-foundation.org, "H. Peter Anvin" <hpa@...ux.intel.com>,
	torvalds@...ux-foundation.org, stable-review@...nel.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400
 workaround

On Wed, Apr 20, 2011 at 05:48:30AM +0100, Ben Hutchings wrote:
> 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@....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.

We got a few new quirks added for AMD hardware platforms that fix
problems.  It took 3 patches to get there, yes, but now, as time goes
on, adding new ones is even easier as the .32 code matches the .39 code
in this area due to these patches being added.

Now if you find problems in these, great, let me know and I will work to
resolve them.

As for regressions, what are you referring to?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/