linux-kernel - Cleanup and updates of x86 CPU definitions

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

Date:	Wed, 27 Aug 2008 21:30:10 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	the arch/x86 maintainers <x86@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Austin Zhang <austin_zhang@...ux.intel.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Cleanup and updates of x86 CPU definitions

Hi all,

I have just committed to tip:x86/cpu the following patch series:

H. Peter Anvin (3):
       x86: generate names for /proc/cpuinfo from <asm/cpufeature.h>
       x86: cpufeature: add Intel features from CPUID and AVX specs
       x86: <asm/cpufeature.h>: clean up overlong lines, whitespace

The combined patch is below.

This changes the CPU feature naming code so that all that information 
comes from <asm-x86/cpufeature.h>.  In the past we have had a number of 
problems with cpufeature.h diverging from what /proc/cpuinfo showed (not 
to mention that at one point we would show different things for 32 and 
64 bits.)

I'm flagging this especially, since this is a patch fairly likely to 
conflict with other changes (incluing in other trees), although 
hopefully in a trivial fashion (this patchset should supercede) since I 
have gone through all the Intel and AMD documentation I could find and 
made sure it has the flags.

It is definitely unfortunate how the kernel sources and /proc/cpuinfo 
use different names for features; given that we can't change 
/proc/cpuinfo it might be worthwhile to run a sed script over the kernel 
sources.

	-hpa

View attachment "log" of type "text/plain" (17390 bytes)