From: Sohil Mehta <sohil.mehta@intel.com>
To: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
Cc: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
<linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v8 2/3] x86/cpu: Check if feature string is non-zero
Date: Mon, 9 Mar 2026 23:23:26 -0700 [thread overview]
Message-ID: <6b177541-91bc-4db9-b073-c5551d9e0bc1@intel.com> (raw)
In-Reply-To: <c67e14b17a3a6a4ee708155082078f58a4131fd3.1772453012.git.m.wieczorretman@pm.me>
On 3/2/2026 7:25 AM, Maciej Wieczor-Retman wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 9aa11224a038..b60269174d95 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -675,6 +675,7 @@ cpuid_dependent_features[] = {
> static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
> {
> const struct cpuid_dependent_feature *df;
> + char feature_buf[16];
>
The usage of number 16 isn't intuitive here. Might be useful to use a
macro here. See below..
> for (df = cpuid_dependent_features; df->feature; df++) {
>
> @@ -697,7 +698,7 @@ static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
> continue;
>
> pr_warn("CPU: CPU feature %s disabled, no CPUID level 0x%x\n",
> - x86_cap_flags[df->feature], df->level);
> + x86_cap_name(df->feature, feature_buf), df->level);
> }
> }
>
> @@ -1634,6 +1635,7 @@ static inline bool parse_set_clear_cpuid(char *arg, bool set)
>
> while (arg) {
> bool found __maybe_unused = false;
> + char name_buf[16];
> unsigned int bit;
>
> opt = strsep(&arg, ",");
> @@ -1654,10 +1656,7 @@ static inline bool parse_set_clear_cpuid(char *arg, bool set)
> setup_clear_cpu_cap(bit);
> }
> /* empty-string, i.e., ""-defined feature flags */
> - if (!x86_cap_flags[bit])
> - pr_cont(" %d:%d\n", bit >> 5, bit & 31);
> - else
> - pr_cont(" %s\n", x86_cap_flags[bit]);
> + pr_cont(" %s\n", x86_cap_name(bit, name_buf));
>
> taint++;
> }
> @@ -1980,6 +1979,23 @@ static void generic_identify(struct cpuinfo_x86 *c)
> #endif
> }
>
It would be useful to have a comment here because the function is called
from multiple files. You can probably reuse the one from the deleted
x86_feature_name().
/*
* Return the feature "name" if available, otherwise return
* the X86_FEATURE_* numerals to make it easier to identify
* the feature.
*/
> +const char *x86_cap_name(unsigned int bit, char *buf)
> +{
> + unsigned int word = bit >> 5;
> + const char *name = NULL;
> +
> + if (likely(word < NCAPINTS))
> + name = x86_cap_flags[bit];
> + else if (likely(word < NCAPINTS + NBUGINTS))
> + name = x86_bug_flags[bit - 32 * NCAPINTS];
> +
> + if (name)
> + return name;
> +
> + snprintf(buf, 16, "%u:%u", word, bit & 31);
The buffer size of 16 is expected to be in sync with the callers and
easy to mess up. Also, the callers wouldn't know that it needs to be 16
because of this snprintf(). Should we have a simple define for it?
Maybe something like,
#define X86_CAP_BUF_SIZE 16
> + return buf;
> +}
> +
> /*
> * This does the hard work of actually picking apart the CPU stuff...
> */
> diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
> index 146f6f8b0650..dfd79b06ab7b 100644
> --- a/arch/x86/kernel/cpu/cpuid-deps.c
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -2,6 +2,7 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/module.h>
Nit:
You can consider adding a newline here.
> +#include <asm/cpu.h>
> #include <asm/cpufeature.h>
>
next prev parent reply other threads:[~2026-03-10 6:23 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
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 [this message]
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=6b177541-91bc-4db9-b073-c5551d9e0bc1@intel.com \
--to=sohil.mehta@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.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=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®