linux-kernel - Re: [34-longterm 181/196] x86, AMD: Fix ARAT feature setting again

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] [day] [month] [year] [list]

Message-ID: <4F60A5E5.1070709@windriver.com>
Date:	Wed, 14 Mar 2012 10:06:29 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Boris Ostrovsky <boris.ostrovsky@....com>
CC:	<stable@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Borislav Petkov <borislav.petkov@....com>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Hans Rosenfeld <hans.rosenfeld@....com>,
	Nick Bowler <nbowler@...iptictech.com>,
	Joerg-Volker-Peetz <jvpeetz@....de>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [34-longterm 181/196] x86, AMD: Fix ARAT feature setting again

On 12-03-13 09:55 AM, Boris Ostrovsky wrote:
> On 03/12/12 20:21, Paul Gortmaker wrote:
>> From: Borislav Petkov<borislav.petkov@....com>
>>
>>                     -------------------
>>      This is a commit scheduled for the next v2.6.34 longterm release.
>>      If you see a problem with using this for longterm, please comment.
> 
> 
> Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the 
> one below.

It turns out that the e9cdd wants to apply on top of (vs instead of) the
14fb57dccb commit.

So I will queue it directly after the 14fb57dcc commit.

Thanks,
Paul.

> 
> -boris
> 
>>                     -------------------
>>
>> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>>
>> Trying to enable the local APIC timer on early K8 revisions
>> uncovers a number of other issues with it, in conjunction with
>> the C1E enter path on AMD. Fixing those causes much more churn
>> and troubles than the benefit of using that timer brings so
>> don't enable it on K8 at all, falling back to the original
>> functionality the kernel had wrt to that.
>>
>> Reported-and-bisected-by: Nick Bowler<nbowler@...iptictech.com>
>> Cc: Boris Ostrovsky<Boris.Ostrovsky@....com>
>> Cc: Andreas Herrmann<andreas.herrmann3@....com>
>> Cc: Greg Kroah-Hartman<greg@...ah.com>
>> Cc: Hans Rosenfeld<hans.rosenfeld@....com>
>> Cc: Nick Bowler<nbowler@...iptictech.com>
>> Cc: Joerg-Volker-Peetz<jvpeetz@....de>
>> Signed-off-by: Borislav Petkov<borislav.petkov@....com>
>> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
>> Signed-off-by: Ingo Molnar<mingo@...e.hu>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@...driver.com>
>> ---
>>   arch/x86/kernel/cpu/amd.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index d618dc1..76a7f76 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>>   #endif
>>
>>   	/* As a rule processors have APIC timer running in deep C states */
>> -	if (c->x86>= 0xf&&  !cpu_has_amd_erratum(amd_erratum_400))
>> +	if (c->x86>  0xf&&  !cpu_has_amd_erratum(amd_erratum_400))
>>   		set_cpu_cap(c, X86_FEATURE_ARAT);
>>
>>   	/*
> 
> 
--
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/