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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4B59E507.9060403@zytor.com>
Date:	Fri, 22 Jan 2010 09:48:55 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...64.org>
CC:	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 01/22/2010 09:40 AM, Borislav Petkov wrote:
>>>
>>> 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.
> 

Bugfixes are *early* -rc candidates.  Regression fixes are *late* -rc
candidates, at least that seems to be the policy Linus currently
implements.  -stable seems to use slightly less strict criteria (the
whole point is that -final needs to be a stabilization point, backported
fixes/drivers can then come onto a stable base) which is why you seem
some patches which are "straight to .1".

> 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.

OK.  You can check with -stable if they want to take the backport post-.33.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/