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 array 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.
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>
Cc: <stable@vger.kernel.org> # 6.18.x
---
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 1c3261cae40c..9aa11224a038 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -732,7 +732,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_INITIALIZER;
__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..b7f4e775a365 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_INITIALIZER\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/2/2026 7:25 AM, Maciej Wieczor-Retman wrote:
> /* 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_INITIALIZER;
IIUC, DISABLED_MASK_INITIALIZER only contains the X86_FEATURE_* bits.
So, the NBUGINTS bits in cpu_caps_cleared[] are implicitly set to 0.
Should that be mentioned in the comment above? It wasn't obvious to me
when I first looked at it.
> __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..b7f4e775a365 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_INITIALIZER\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";
On 2026-03-09 at 16:47:49 -0700, Sohil Mehta wrote: >On 3/2/2026 7:25 AM, Maciej Wieczor-Retman wrote: > >> /* 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_INITIALIZER; > >IIUC, DISABLED_MASK_INITIALIZER only contains the X86_FEATURE_* bits. >So, the NBUGINTS bits in cpu_caps_cleared[] are implicitly set to 0. > >Should that be mentioned in the comment above? It wasn't obvious to me >when I first looked at it. As I understand the features can be compile time disabled while bugs can't? So it wouldn't be practical to initialize the BUGS part of cpu_caps_cleared. But I suppose it doesn't hurt to clarify it in the patch message. -- Kind regards Maciej Wieczór-Retman
On Mon, Mar 02, 2026 at 03:25:10PM +0000, 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.
>
> Once the cpu_caps_cleared array 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'
All your text: s/cpu/CPU/g
> cpu_data.x86_capability[]. Thus features disabled at compile time won't
> show up in /proc/cpuinfo.
>
> 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>
> Cc: <stable@vger.kernel.org> # 6.18.x
So why is this going to stable anyway?
What is the serious issue this is fixing? Really...?
> ---
> 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 1c3261cae40c..9aa11224a038 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -732,7 +732,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_INITIALIZER;
DISABLED_MASK_INIT is kinda obvious already.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-02 at 20:31:42 +0100, Borislav Petkov wrote: >On Mon, Mar 02, 2026 at 03:25:10PM +0000, 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. >> >> Once the cpu_caps_cleared array 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' > >All your text: s/cpu/CPU/g Sure, I'll change it. > >> cpu_data.x86_capability[]. Thus features disabled at compile time won't >> show up in /proc/cpuinfo. >> >> 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> >> Cc: <stable@vger.kernel.org> # 6.18.x > >So why is this going to stable anyway? > >What is the serious issue this is fixing? Really...? The documentation from at least 5.10 onwards promises to have flags in cpuinfo only if they're truly compiled and enabled. So I thought that incosistency can be corrected from that point on. For the 6.18 stable kernel this particular patch applies cleanly because it already started using the awk script. For the older ones I took Greg's advice and prepared separate patch that worked before the awk script was introduced. >> --- >> 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 1c3261cae40c..9aa11224a038 100644 >> --- a/arch/x86/kernel/cpu/common.c >> +++ b/arch/x86/kernel/cpu/common.c >> @@ -732,7 +732,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_INITIALIZER; > >DISABLED_MASK_INIT is kinda obvious already. Okay, I'll shorten it. > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette -- Kind regards Maciej Wieczór-Retman
On Mon, Mar 02, 2026 at 07:48:41PM +0000, Maciej Wieczor-Retman wrote:
> The documentation from at least 5.10 onwards promises to have flags in cpuinfo
> only if they're truly compiled and enabled. So I thought that incosistency can
> be corrected from that point on. For the 6.18 stable kernel this particular
> patch applies cleanly because it already started using the awk script. For the
> older ones I took Greg's advice and prepared separate patch that worked before
> the awk script was introduced.
I don't think you got my question, lemme try again:
How serious is this bug so that you want to backport it to stable?
So what if some flags appear in /proc/cpuinfo even if they're not compiled in?
Is the cat going to catch fire or no one cares...?
IOW, does it really need to go to stable and if so, what's the grave bug it is
fixing?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-02 at 21:25:04 +0100, Borislav Petkov wrote: >On Mon, Mar 02, 2026 at 07:48:41PM +0000, Maciej Wieczor-Retman wrote: >> The documentation from at least 5.10 onwards promises to have flags in cpuinfo >> only if they're truly compiled and enabled. So I thought that incosistency can >> be corrected from that point on. For the 6.18 stable kernel this particular >> patch applies cleanly because it already started using the awk script. For the >> older ones I took Greg's advice and prepared separate patch that worked before >> the awk script was introduced. > >I don't think you got my question, lemme try again: > >How serious is this bug so that you want to backport it to stable? > >So what if some flags appear in /proc/cpuinfo even if they're not compiled in? > >Is the cat going to catch fire or no one cares...? > >IOW, does it really need to go to stable and if so, what's the grave bug it is >fixing? I don't think it's some big threat. But then would you agree it'd be a good idea to backport a change to the documentation that the cpuinfo isn't as reliable as the documentation entry says it is? I would imagine the documentation should be kept as accurate as possible. -- Kind regards Maciej Wieczór-Retman
On Mon, Mar 02, 2026 at 08:38:35PM +0000, Maciej Wieczor-Retman wrote:
> I don't think it's some big threat. But then would you agree it'd be a good idea
> to backport a change to the documentation that the cpuinfo isn't as reliable as
> the documentation entry says it is? I would imagine the documentation should be
> kept as accurate as possible.
Point me to which rule your argumentation applies, pls:
Documentation/process/stable-kernel-rules.rst
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-02 at 21:59:47 +0100, Borislav Petkov wrote: >On Mon, Mar 02, 2026 at 08:38:35PM +0000, Maciej Wieczor-Retman wrote: >> I don't think it's some big threat. But then would you agree it'd be a good idea >> to backport a change to the documentation that the cpuinfo isn't as reliable as >> the documentation entry says it is? I would imagine the documentation should be >> kept as accurate as possible. > >Point me to which rule your argumentation applies, pls: > >Documentation/process/stable-kernel-rules.rst > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette Maybe it could fall under the 'some "oh, that's not good" issue'? :) But I see your point, I'll drop sending it to stable. -- Kind regards Maciej Wieczór-Retman
On March 2, 2026 9:22:47 PM UTC, Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote: >Maybe it could fall under the 'some "oh, that's not good" issue'? :) More like "no one noticed/complained until now so why are we making waves and generating unnecessary work now" thing... -- Small device. Typos and formatting crap
© 2016 - 2026 Red Hat, Inc.