mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Farrah Chen <farrah.chen@intel.com>,
	Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 1/3] x86/cpu: Clear feature bits disabled at compile-time
Date: Mon, 2 Mar 2026 20:31:42 +0100	[thread overview]
Message-ID: <20260302193142.GBaaXlnu86gUtPyQG6@fat_crate.local> (raw)
In-Reply-To: <cb4c2a6a0e67320b24244658b724acc1bf9686ef.1772453012.git.m.wieczorretman@pm.me>

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

  reply	other threads:[~2026-03-02 19:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02 15:24 [PATCH v8 0/3] x86: Capability bits fix and required bits sanity check Maciej Wieczor-Retman
2026-03-02 15:25 ` [PATCH v8 1/3] x86/cpu: Clear feature bits disabled at compile-time Maciej Wieczor-Retman
2026-03-02 19:31   ` Borislav Petkov [this message]
2026-03-02 19:48     ` Maciej Wieczor-Retman
2026-03-02 20:25       ` Borislav Petkov
2026-03-02 20:38         ` Maciej Wieczor-Retman
2026-03-02 20:59           ` Borislav Petkov
2026-03-02 21:22             ` Maciej Wieczor-Retman
2026-03-03  5:59               ` Borislav Petkov
2026-03-09 23:47   ` Sohil Mehta
2026-03-10 10:49     ` Maciej Wieczor-Retman
2026-03-02 15:25 ` [PATCH v8 2/3] x86/cpu: Check if feature string is non-zero Maciej Wieczor-Retman
2026-03-10  6:23   ` Sohil Mehta
2026-03-10 12:29     ` Maciej Wieczor-Retman
2026-03-02 15:25 ` [PATCH v8 3/3] x86/cpu: Do a sanity check on required feature bits Maciej Wieczor-Retman
2026-03-10  7:05   ` Sohil Mehta
2026-03-10 13:06     ` Maciej Wieczor-Retman

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=20260302193142.GBaaXlnu86gUtPyQG6@fat_crate.local \
    --to=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=farrah.chen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.wieczorretman@pm.me \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®