From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
If some config options are disabled during compile time, they still are
enumerated in macros that use the x86_capability bitmask - cpu_has() or
this_cpu_has().
The features are also visible in /proc/cpuinfo even though they are not
enabled - which is contrary to what the documentation states about the
file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced,
split_lock_detect, user_shstk, avx_vnni and enqcmd.
Once the cpu_caps_cleared[] is initialized with the autogenerated
disabled bitmask apply_forced_caps() will clear the corresponding bits
in boot_cpu_data.x86_capability[] and other secondary CPUs'
cpu_data.x86_capability[]. Thus features disabled at compile time won't
show up in /proc/cpuinfo.
No BUGS are defined to be cleared at compile time, therefore only the
NCAPINTS part of cpu_caps_cleared[] is initialized. The NBUGINTS part is
set initialized to zero.
Reported-by: Farrah Chen <farrah.chen@intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220348
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v9:
- *_MASK_INITIALIZER -> *_MASK_INIT
- Remove Cc stable.
- Note that the BUGS part of cpu_caps_cleared[] is zeroed.
Changelog v6:
- Remove patch message portions that are not just describing the diff.
arch/x86/kernel/cpu/common.c | 3 ++-
arch/x86/tools/cpufeaturemasks.awk | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..76339e988304 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -735,7 +735,8 @@ static const char *table_lookup_model(struct cpuinfo_x86 *c)
}
/* Aligned to unsigned long to avoid split lock in atomic bitmap ops */
-__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
+__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long)) =
+ DISABLED_MASK_INIT;
__u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
#ifdef CONFIG_X86_32
diff --git a/arch/x86/tools/cpufeaturemasks.awk b/arch/x86/tools/cpufeaturemasks.awk
index 173d5bf2d999..9382bd15279a 100755
--- a/arch/x86/tools/cpufeaturemasks.awk
+++ b/arch/x86/tools/cpufeaturemasks.awk
@@ -82,6 +82,12 @@ END {
}
printf " 0\t\\\n";
printf "\t) & (1U << ((x) & 31)))\n\n";
+
+ printf "\n#define %s_MASK_INIT\t\t\t\\", s;
+ printf "\n\t{\t\t\t\t\t\t\\";
+ for (i = 0; i < ncapints; i++)
+ printf "\n\t\t%s_MASK%d,\t\t\t\\", s, i;
+ printf "\n\t}\n\n";
}
printf "#endif /* _ASM_X86_CPUFEATUREMASKS_H */\n";
--
2.53.0On 3/10/2026 11:03 AM, Maciej Wieczor-Retman wrote: > From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> > > If some config options are disabled during compile time, they still are > enumerated in macros that use the x86_capability bitmask - cpu_has() or > this_cpu_has(). > > The features are also visible in /proc/cpuinfo even though they are not > enabled - which is contrary to what the documentation states about the > file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced, > split_lock_detect, user_shstk, avx_vnni and enqcmd. > Do all of these features have compile time options today? For example, I couldn't find X86_DISABLED_FEATURE_* equivalent for ibrs_enhanced, split_lock_detect or avx_vnni. Maybe I am missing some obvious connection. But, if these can't be disabled using config options, it would be better to avoid any mention of them here. > Once the cpu_caps_cleared[] is initialized with the autogenerated > disabled bitmask apply_forced_caps() will clear the corresponding bits > in boot_cpu_data.x86_capability[] and other secondary CPUs' This sentence was a bit hard to read for me. How about? Initialize cpu_caps_cleared[] with an autogenerated disabled bitmask. During CPU init, apply_forced_caps() will clear the corresponding bits in struct cpuinfo_x86 for each CPU. Thus features disabled at... > cpu_data.x86_capability[]. Thus features disabled at compile time won't > show up in /proc/cpuinfo. > > No BUGS are defined to be cleared at compile time, therefore only the > NCAPINTS part of cpu_caps_cleared[] is initialized. The NBUGINTS part is ..NCAPINTS part of cpu_caps_cleared[] is initialized using the macro. The NBUGINTS part is set to zero. > set initialized to zero. > You don't need the word 'initialized' here. > Reported-by: Farrah Chen <farrah.chen@intel.com> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220348 > Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> > --- > arch/x86/kernel/cpu/common.c | 3 ++- > arch/x86/tools/cpufeaturemasks.awk | 6 ++++++ > 2 files changed, 8 insertions(+), 1 deletion(-) > The code changes look good to me, Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
On 2026-03-10 at 15:00:30 -0700, Sohil Mehta wrote: >On 3/10/2026 11:03 AM, Maciej Wieczor-Retman wrote: >> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> >> >> If some config options are disabled during compile time, they still are >> enumerated in macros that use the x86_capability bitmask - cpu_has() or >> this_cpu_has(). >> >> The features are also visible in /proc/cpuinfo even though they are not >> enabled - which is contrary to what the documentation states about the >> file. Examples of such feature flags are lam, fred, sgx, ibrs_enhanced, >> split_lock_detect, user_shstk, avx_vnni and enqcmd. >> > >Do all of these features have compile time options today? For example, I >couldn't find X86_DISABLED_FEATURE_* equivalent for ibrs_enhanced, >split_lock_detect or avx_vnni. Maybe I am missing some obvious connection. > >But, if these can't be disabled using config options, it would be better >to avoid any mention of them here. Okay, I'll clean this up. I included these because previously I intended to backport the changes as far as the documentation specified cpuinfo should work this way. But yeah, now that we're not doing that it's best to remove them. Thanks! > >> Once the cpu_caps_cleared[] is initialized with the autogenerated >> disabled bitmask apply_forced_caps() will clear the corresponding bits >> in boot_cpu_data.x86_capability[] and other secondary CPUs' > >This sentence was a bit hard to read for me. How about? > >Initialize cpu_caps_cleared[] with an autogenerated disabled bitmask. >During CPU init, apply_forced_caps() will clear the corresponding bits >in struct cpuinfo_x86 for each CPU. Thus features disabled at... That works for me, the version above was my attempt to describe the diff as little as possible while keeping the relevant information. Perhaps that sentence got a bit too long. >> cpu_data.x86_capability[]. Thus features disabled at compile time won't >> show up in /proc/cpuinfo. >> >> No BUGS are defined to be cleared at compile time, therefore only the >> NCAPINTS part of cpu_caps_cleared[] is initialized. The NBUGINTS part is > >..NCAPINTS part of cpu_caps_cleared[] is initialized using the macro. >The NBUGINTS part is set to zero. > >> set initialized to zero. >> > >You don't need the word 'initialized' here. Okay, I'll remove it. > >> Reported-by: Farrah Chen <farrah.chen@intel.com> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220348 >> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> >> --- > >> arch/x86/kernel/cpu/common.c | 3 ++- >> arch/x86/tools/cpufeaturemasks.awk | 6 ++++++ >> 2 files changed, 8 insertions(+), 1 deletion(-) >> > >The code changes look good to me, > >Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> > Thanks :) -- Kind regards Maciej Wieczór-Retman
© 2016 - 2026 Red Hat, Inc.