From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, Thomas Gleixner <tglx@linutronix.de>,
Andi Kleen <ak@linux.intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>
Subject: [PATCH 4.14 03/34] x86/cpufeature: Fix various quality problems in the <asm/cpu_device_hd.h> header
Date: Mon, 31 Oct 2022 08:02:36 +0100 [thread overview]
Message-ID: <20221031070140.193632481@linuxfoundation.org> (raw)
In-Reply-To: <20221031070140.108124105@linuxfoundation.org>
From: Ingo Molnar <mingo@kernel.org>
commit 266d63a7d9d48c6d5dee486378ec0e8c86c4d74a upstream
Thomas noticed that the new arch/x86/include/asm/cpu_device_id.h header is
a train-wreck that didn't incorporate review feedback like not using __u8
in kernel-only headers.
While at it also fix all the *other* problems this header has:
- Use canonical names for the header guards. It's inexplicable why a non-standard
guard was used.
- Don't define the header guard to 1. Plus annotate the closing #endif as done
absolutely every other header. Again, an inexplicable source of noise.
- Move the kernel API calls provided by this header next to each other, there's
absolutely no reason to have them spread apart in the header.
- Align the INTEL_CPU_DESC() macro initializations vertically, this is easier to
read and it's also the canonical style.
- Actually name the macro arguments properly: instead of 'mod, step, rev',
spell out 'model, stepping, revision' - it's not like we have a lack of
characters in this header.
- Actually make arguments macro-safe - again it's inexplicable why it wasn't
done properly to begin with.
Quite amazing how many problems a 41 lines header can contain.
This kind of code quality is unacceptable, and it slipped through the
review net of 2 developers and 2 maintainers, including myself, until
Thomas noticed it. :-/
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/cpu_device_id.h | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _CPU_DEVICE_ID
-#define _CPU_DEVICE_ID 1
+#ifndef _ASM_X86_CPU_DEVICE_ID
+#define _ASM_X86_CPU_DEVICE_ID
/*
* Declare drivers belonging to specific x86 CPUs
@@ -9,8 +9,6 @@
#include <linux/mod_devicetable.h>
-extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
-
/*
* Match specific microcode revisions.
*
@@ -22,21 +20,22 @@ extern const struct x86_cpu_id *x86_matc
*/
struct x86_cpu_desc {
- __u8 x86_family;
- __u8 x86_vendor;
- __u8 x86_model;
- __u8 x86_stepping;
- __u32 x86_microcode_rev;
+ u8 x86_family;
+ u8 x86_vendor;
+ u8 x86_model;
+ u8 x86_stepping;
+ u32 x86_microcode_rev;
};
-#define INTEL_CPU_DESC(mod, step, rev) { \
- .x86_family = 6, \
- .x86_vendor = X86_VENDOR_INTEL, \
- .x86_model = mod, \
- .x86_stepping = step, \
- .x86_microcode_rev = rev, \
+#define INTEL_CPU_DESC(model, stepping, revision) { \
+ .x86_family = 6, \
+ .x86_vendor = X86_VENDOR_INTEL, \
+ .x86_model = (model), \
+ .x86_stepping = (stepping), \
+ .x86_microcode_rev = (revision), \
}
+extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
extern bool x86_cpu_has_min_microcode_rev(const struct x86_cpu_desc *table);
-#endif
+#endif /* _ASM_X86_CPU_DEVICE_ID */
next prev parent reply other threads:[~2022-10-31 7:03 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 7:02 [PATCH 4.14 00/34] 4.14.297-rc1 review Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 01/34] Revert "x86/cpu: Add a steppings field to struct x86_cpu_id" Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 02/34] x86/cpufeature: Add facility to check for min microcode revisions Greg Kroah-Hartman
2022-10-31 7:02 ` Greg Kroah-Hartman [this message]
2022-10-31 7:02 ` [PATCH 4.14 04/34] x86/devicetable: Move x86 specific macro out of generic code Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 05/34] x86/cpu: Add consistent CPU match macros Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 06/34] x86/cpu: Add a steppings field to struct x86_cpu_id Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 07/34] x86/entry: Remove skip_r11rcx Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 08/34] x86/cpufeatures: Move RETPOLINE flags to word 11 Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 09/34] x86/bugs: Report AMD retbleed vulnerability Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 10/34] x86/bugs: Add AMD retbleed= boot parameter Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 11/34] x86/bugs: Keep a per-CPU IA32_SPEC_CTRL value Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 12/34] x86/entry: Add kernel IBRS implementation Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 13/34] x86/bugs: Optimize SPEC_CTRL MSR writes Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 14/34] x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 15/34] x86/bugs: Split spectre_v2_select_mitigation() and spectre_v2_user_select_mitigation() Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 16/34] x86/bugs: Report Intel retbleed vulnerability Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 17/34] entel_idle: Disable IBRS during long idle Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 18/34] x86/speculation: Change FILL_RETURN_BUFFER to work with objtool Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 19/34] x86/speculation: Add LFENCE to RSB fill sequence Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 20/34] x86/speculation: Fix RSB filling with CONFIG_RETPOLINE=n Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 21/34] x86/speculation: Fix firmware entry SPEC_CTRL handling Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 22/34] x86/speculation: Fix SPEC_CTRL write on SMT state change Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 23/34] x86/speculation: Use cached host SPEC_CTRL value for guest entry/exit Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 24/34] x86/speculation: Remove x86_spec_ctrl_mask Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 25/34] KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS Greg Kroah-Hartman
2022-10-31 7:02 ` [PATCH 4.14 26/34] KVM: VMX: Fix IBRS handling after vmexit Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 27/34] x86/speculation: Fill RSB on vmexit for IBRS Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 28/34] x86/common: Stamp out the stepping madness Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 29/34] x86/cpu/amd: Enumerate BTC_NO Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 30/34] x86/bugs: Add Cannon lake to RETBleed affected CPU list Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 31/34] x86/speculation: Disable RRSBA behavior Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 32/34] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 33/34] x86/bugs: Warn when "ibrs" mitigation is selected on Enhanced IBRS parts Greg Kroah-Hartman
2022-10-31 7:03 ` [PATCH 4.14 34/34] x86/speculation: Add RSB VM Exit protections Greg Kroah-Hartman
2022-10-31 11:05 ` [PATCH 4.14 00/34] 4.14.297-rc1 review Jon Hunter
2022-11-01 8:07 ` Naresh Kamboju
2022-11-01 12:51 ` Guenter Roeck
-- strict thread matches above, loose matches on Subject: below --
2022-10-27 20:48 [PATCH 4.14 00/34] Retbleed & PBRSB Mitigations Suraj Jitindar Singh
2022-10-27 20:54 ` [PATCH 4.14 01/34] Revert "x86/cpu: Add a steppings field to struct x86_cpu_id" Suraj Jitindar Singh
2022-10-27 20:54 ` [PATCH 4.14 03/34] x86/cpufeature: Fix various quality problems in the <asm/cpu_device_hd.h> header Suraj Jitindar Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221031070140.193632481@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.