[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87bk54jh36.ffs@tglx>
Date: Fri, 17 May 2024 22:53:17 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Luck, Tony" <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de>
Cc: Ingo Molnar <mingo@...hat.com>, Dave
Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H.
Peter Anvin" <hpa@...or.com>, "Peter Zijlstra (Intel)"
<peterz@...radead.org>, Uros Bizjak <ubizjak@...il.com>, "Edgecombe, Rick
P" <rick.p.edgecombe@...el.com>, Arnd Bergmann <arnd@...db.de>, Mateusz
Guzik <mjguzik@...il.com>, Thomas Renninger <trenn@...e.de>, Greg
Kroah-Hartman <gregkh@...e.de>, Andi Kleen <ak@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v3] x86/cpu: Fix x86_match_cpu() to match just
X86_VENDOR_INTEL
On Fri, May 17 2024 at 18:13, Luck, Tony wrote:
>>> for (m = match; m->flags & X86_CPU_ID_FLAG_ENTRY_VALID; m++) {
>>
>> Yeah, makes sense at a first glance.
>>
>> This'll keep the terminators "{}" unchanged so that we don't have to
>> touch all those gazillion places and it'll explicitly state that an
>> entry is valid or not.
>
>> But the devil's in the detail, as always...
>
> Yes. One detail is that there are places not using the X86_MATCH
> macros.
Groan.
> E.g. in arch/x86/crypto/aesni-intel_glue.c there is:
>
> static const struct x86_cpu_id zmm_exclusion_list[] = {
> { .vendor = X86_VENDOR_INTEL, .family = 6, .model = INTEL_FAM6_SKYLAKE_X },
> ...
> };
>
> This one (and likely most/all others) will be fixed by the remaining
> patches in my new families[1] series.
AFAICT, that's the only one.
# git grep -C5 'struct x86_cpu_id' | grep '\.vendor' | awk '{ print $1; }' | uniq
arch/x86/crypto/aesni-intel_glue.c-
Powered by blists - more mailing lists