public inbox for patches@lists.linux.dev
 help / color / mirror / Atom feed
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>,
	Suleiman Souhlal <suleiman@google.com>
Subject: [PATCH 4.19 04/34] x86/cpufeature: Fix various quality problems in the <asm/cpu_device_hd.h> header
Date: Mon, 21 Nov 2022 13:43:26 +0100	[thread overview]
Message-ID: <20221121124151.029399009@linuxfoundation.org> (raw)
In-Reply-To: <20221121124150.886779344@linuxfoundation.org>

From: Ingo Molnar <mingo@kernel.org>

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: Suleiman Souhlal <suleiman@google.com>
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 */



  parent reply	other threads:[~2022-11-21 12:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 12:43 [PATCH 4.19 00/34] 4.19.266-rc1 review Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 01/34] Revert "x86/speculation: Add RSB VM Exit protections" Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 02/34] Revert "x86/cpu: Add a steppings field to struct x86_cpu_id" Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 03/34] x86/cpufeature: Add facility to check for min microcode revisions Greg Kroah-Hartman
2022-11-21 12:43 ` Greg Kroah-Hartman [this message]
2022-11-21 12:43 ` [PATCH 4.19 05/34] x86/devicetable: Move x86 specific macro out of generic code Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 06/34] x86/cpu: Add consistent CPU match macros Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 07/34] x86/cpu: Add a steppings field to struct x86_cpu_id Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 08/34] x86/cpufeatures: Move RETPOLINE flags to word 11 Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 09/34] x86/bugs: Report AMD retbleed vulnerability Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 10/34] x86/bugs: Add AMD retbleed= boot parameter Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 11/34] x86/bugs: Keep a per-CPU IA32_SPEC_CTRL value Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 12/34] x86/entry: Remove skip_r11rcx Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 13/34] x86/entry: Add kernel IBRS implementation Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 14/34] x86/bugs: Optimize SPEC_CTRL MSR writes Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 15/34] x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 16/34] x86/bugs: Split spectre_v2_select_mitigation() and spectre_v2_user_select_mitigation() Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 17/34] x86/bugs: Report Intel retbleed vulnerability Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 18/34] intel_idle: Disable IBRS during long idle Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 19/34] x86/speculation: Change FILL_RETURN_BUFFER to work with objtool Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 20/34] x86/speculation: Fix RSB filling with CONFIG_RETPOLINE=n Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 21/34] x86/speculation: Fix firmware entry SPEC_CTRL handling Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 22/34] x86/speculation: Fix SPEC_CTRL write on SMT state change Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 23/34] x86/speculation: Use cached host SPEC_CTRL value for guest entry/exit Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 24/34] x86/speculation: Remove x86_spec_ctrl_mask Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 25/34] KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 26/34] KVM: VMX: Fix IBRS handling after vmexit Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 27/34] x86/speculation: Fill RSB on vmexit for IBRS Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 28/34] x86/common: Stamp out the stepping madness Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 29/34] x86/cpu/amd: Enumerate BTC_NO Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 30/34] x86/bugs: Add Cannon lake to RETBleed affected CPU list Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 31/34] x86/speculation: Disable RRSBA behavior Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 32/34] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 33/34] x86/bugs: Warn when "ibrs" mitigation is selected on Enhanced IBRS parts Greg Kroah-Hartman
2022-11-21 12:43 ` [PATCH 4.19 34/34] x86/speculation: Add RSB VM Exit protections Greg Kroah-Hartman
2022-11-21 18:47 ` [PATCH 4.19 00/34] 4.19.266-rc1 review Shuah Khan
2022-11-21 19:02 ` Pavel Machek
2022-11-22  6:29 ` Naresh Kamboju
2022-11-22 10:16 ` Jon Hunter
2022-11-22 16:58 ` Guenter Roeck

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=20221121124151.029399009@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=suleiman@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox