linux-kernel - Re: [PATCH -v3 0/5] x86, cacheinfo, amd: L3 Cache Index Disable fixes

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 22 Jan 2010 18:40:49 +0100
From:	Borislav Petkov <bp@...64.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...64.org>, mingo@...e.hu, tglx@...utronix.de,
	andreas.herrmann3@....com, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -v3 0/5] x86, cacheinfo, amd: L3 Cache Index Disable
 fixes

On Fri, Jan 22, 2010 at 09:24:28AM -0800, H. Peter Anvin wrote:
> On 01/22/2010 07:01 AM, Borislav Petkov wrote:
> > these are a bunch of fixes which correct the disabling of L3 cache
> > indexes. This is needed, for example, in the case when excessive
> > correctable L3 error rates are observed. In a later step, this
> > functionality will be connected to the mcheck mechanism and used to
> > evaluate occurring L3 tag and data array errors and then disable the
> > respective failing L3 cache regions in order to defer system failure
> > before a sysop can intervene.
> > 
> > Those patches are also good -stable candidates.
> 
> Hmmm... I'm not sure I see a strong justification for a late -rc push
> into Linus/stable push for for these... I think you would have to
> explicitly make the case if you want them to be considered as such.

Well, on the one hand, they fix real bugs in the L3 cache index disable
code and since they're bugfixes, they are eligible late -rc candidates.

On the other hand, however and more importantly, the machines which
have that feature are not selling yet so postponing the patches for the
next merge window is still ok. I'll backport them then to .32 for the
distro kernels and .33 and I think we are going to be fine this way.

So queueing them for .34 is still fine with me, thanks.

-- 
Regards/Gruss,
ボリス.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
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/