From nobody Sat Apr 4 07:49:33 2026 Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch [79.135.106.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 470F33B2FE0 for ; Fri, 20 Mar 2026 12:50:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.118 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011023; cv=none; b=sVog2gPwSyLmK0tyFt7z0VVJW3FCWNPPUolye2QIYWTiqyltDnAYX1076keEQq/sCDEzcwG5OqsUq9BB22irynj23ezLyvrv6bIdc2b+z3gx1aCY8ur19Bcj866HFj4uEQd+v2xXRtoX2QFM9VT1F+PmPI45TJU/9tbS1J+cC/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011023; c=relaxed/simple; bh=mEEXKUlmkVBIzNV5wtuGiKeQL7kp/lCT/CJFn9Wdi4I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=eC+fufR9qYUrdeSNbnkQskdmQto5VN5lQG9zC3yTZ9gPqQ2CI8Fw/qIs0ZthbG/3hEn/QBppWBaOnTkHkVtUPAh98THQJIf4RmZScYWKBMgCkQOtzyI8zyT5SFXWfQmNkkK94mUJ7xsPHfTQ0ZKo+koYIvGsTFQVJED2LBT/M4I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=KJCGJ6Kv; arc=none smtp.client-ip=79.135.106.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="KJCGJ6Kv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774011019; x=1774270219; bh=mWI6Ci0OExEN/NmgLmPa48Tm+LQjRqPyhRE3t1Uth/U=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=KJCGJ6KvzzvHYbbowh+HZpgjsQqSU1eapmchL001u543bTmFcZy+ljryCYzrl+/zT /jOvy/jnoEhPhSifaaR+0pT7B/G0fgSPG9B3W66G0dDxX51o+i7XeFsQq9dkJjeiJF UNo56IPgtJRWyLhXBQX/7tIwchBALjcCAEl6R7WcahOUZQR6pQbI8flJclidZNS/Uw XXqQ5iBUcLOWeq5sv95odpGyzCN5ywHWqAUJ3iPJlFVSOxnkL0qzehfs9MQ1wP1Sve jVDq0v1Ph6ouxNZVWOdeA3SzwhGRyeYtwaZ21alNR9PRQiROP5iNg30pwiFi402gOf DUiUYxOM8ELNQ== Date: Fri, 20 Mar 2026 12:50:14 +0000 To: tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, bp@alien8.de, mingo@redhat.com From: Maciej Wieczor-Retman Cc: x86@kernel.org, linux-kernel@vger.kernel.org, m.wieczorretman@pm.me, Farrah Chen Subject: [PATCH v11 1/4] x86/cpu: Clear feature bits disabled at compile-time Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: d7cf72c11a5c0878c008daeaf7501b3657e4f02e Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman 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, user_shstk and enqcmd. 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 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 using the macro. The NBUGINTS part is set to zero. Reported-by: Farrah Chen Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D220348 Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Sohil Mehta --- Changelog v10: - Remove examples of feature flags that came from stable kernels. - Redo the patch message a bit with Sohil's suggestions. - Add Sohil's Reviewed-by tag. 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_x8= 6 *c) } =20 /* 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= )) =3D + DISABLED_MASK_INIT; __u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long)); =20 #ifdef CONFIG_X86_32 diff --git a/arch/x86/tools/cpufeaturemasks.awk b/arch/x86/tools/cpufeature= masks.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 =3D 0; i < ncapints; i++) + printf "\n\t\t%s_MASK%d,\t\t\t\\", s, i; + printf "\n\t}\n\n"; } =20 printf "#endif /* _ASM_X86_CPUFEATUREMASKS_H */\n"; --=20 2.53.0 From nobody Sat Apr 4 07:49:33 2026 Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch [109.224.244.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCFB03ACA48 for ; Fri, 20 Mar 2026 12:50:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011033; cv=none; b=ENBNTwiycPZ4jy+0nByXFc0Zs+MDmt/qLD7GsjHYOuVHT792tlW0ks0s2DCQmnxXj+Abz39z0r3MbFqMsQcSSrq9/G2s99wt7E4sz0TbOVNYv1HtAUh8m2fYse7eyr8mnHNaSgMGoN+Z5wT3m65I1rTCUnW1lmb/DnKiSc0GKic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011033; c=relaxed/simple; bh=0TMTJ+/sQp4HofRFiT7rYJz7dZWsZE3m6Yma/3BWdxw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rGq8/fV+DUWI20sjd3Yql+TI3vrU42yuhYwcTxR2qdEpAdzuoqMse4Knx2/QHeL5wn6i3rkss2tBuABBtHtvNphE7VEMpagosrVSt1j0lUvy6htlaDBCwlScnWuhiFck52q6N0QaYRdvFo9dZ+Fh1fpULJOv7zfA44VoYZ5Y6AU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=JF5tTTnm; arc=none smtp.client-ip=109.224.244.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="JF5tTTnm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774011023; x=1774270223; bh=tK1nWH2xfxAb0Jum6u9c6N7SnbnUcnGmBdMuJLsHYms=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=JF5tTTnme87nZym3UI8WZ684q/CeGYMjOksGg7um4b1vGRs3EbvNis2/qSYPGw6iS uAFWYvgxpBaUvuiZD5RjLH5qMr+R5utFbPCVQbRfpW+4NrrbnwvyQ80wqEvB+n36th BedU3o9QBKXWDHJem3UHUnLPQoX69x+jsM0r6XUTzpbSd6MRe5/F6QrZRkX/cgYtNk FwvUFYxllhm8AeRppJYg7cEnPeviIX4vrvfvkYL31cy3U0nYYoCbiLfJfgKrT6Mm13 Fd+fLS2U7iGyI15YS5WppjL1Wsp8RFrslGKrDy/Q8Yn2N9skmManlqt+62JxN935zz Rxr22+hu80s0w== Date: Fri, 20 Mar 2026 12:50:19 +0000 To: tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, bp@alien8.de, mingo@redhat.com From: Maciej Wieczor-Retman Cc: x86@kernel.org, linux-kernel@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v11 2/4] x86/cpu: Check if feature string is non-zero Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: a644aa7c4b8f42a0f6bc6fa0aee64d6eabb3afe0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman In filter_cpuid_features(), x86_cap_flags[] is read, but it's not verified whether the string is non-zero which could lead to unwanted output. In two more places there are open coded paths that try to retrieve a feature string, and if there isn't one, the feature word and bit are returned instead. Add a common helper to fix filter_cpuid_features() as well as clean up the open coded cases. Signed-off-by: Maciej Wieczor-Retman Reviewed-by: Sohil Mehta Reviewed-by: Pawan Gupta --- Changelog v11: - Remove one extra tab after X86_CAP_BUF_SIZE. - Add Reviewed-by tags from Sohil and Pawan. Changelog v10: - Reword the patch message a bit. - Move x86_cap_name() declaration and X86_CAP_BUF_SIZE define to asm/cpufeature.h. - Don't include asm/cpu.h in cpuid-deps.c - Extend the comment above x86_cap_name to include information on buffer size that needs to be prepared before calling the function. - Remove the likely(), unlikely() calls since this is not a hot path. Changelog v9: - 16 -> X86_CAP_BUF_SIZE. - Add comment to the x86_cap_name(). Changelog v8: - Move x86_cap_name() declaration from linux/cpu.h to the arch/cpu.h. Include arch/cpu.h in the cpuid-deps.c file instead of linux/cpu.h. Changelog v7: - sizeof(buf) -> 16 - Rebase onto 7.01-rc1. Changelog v6: - Remove parts of the patch message that are redundant and just copy what's visible in the diff. - Redo the helper to use an external char buffer instead of a local static string. arch/x86/include/asm/cpufeature.h | 4 ++++ arch/x86/kernel/cpu/common.c | 32 ++++++++++++++++++++++++++----- arch/x86/kernel/cpu/cpuid-deps.c | 21 +++----------------- 3 files changed, 34 insertions(+), 23 deletions(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufe= ature.h index 3ddc1d33399b..0698a6638463 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -138,5 +138,9 @@ static __always_inline bool _static_cpu_has(u16 bit) #define CPU_FEATURE_TYPEVAL boot_cpu_data.x86_vendor, boot_cpu_data.x86, \ boot_cpu_data.x86_model =20 +#define X86_CAP_BUF_SIZE 16 + +const char *x86_cap_name(unsigned int bit, char *buf); + #endif /* defined(__KERNEL__) && !defined(__ASSEMBLER__) */ #endif /* _ASM_X86_CPUFEATURE_H */ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 76339e988304..0e318f3d56cb 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -678,6 +678,7 @@ cpuid_dependent_features[] =3D { static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) { const struct cpuid_dependent_feature *df; + char feature_buf[X86_CAP_BUF_SIZE]; =20 for (df =3D cpuid_dependent_features; df->feature; df++) { =20 @@ -700,7 +701,7 @@ static void filter_cpuid_features(struct cpuinfo_x86 *c= , bool warn) continue; =20 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); } } =20 @@ -1637,6 +1638,7 @@ static inline bool parse_set_clear_cpuid(char *arg, b= ool set) =20 while (arg) { bool found __maybe_unused =3D false; + char name_buf[X86_CAP_BUF_SIZE]; unsigned int bit; =20 opt =3D strsep(&arg, ","); @@ -1657,10 +1659,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)); =20 taint++; } @@ -1983,6 +1982,29 @@ static void generic_identify(struct cpuinfo_x86 *c) #endif } =20 +/* + * Return the feature "name" if available, otherwise return the + * X86_FEATURE_* numerals to make it easier to identify the feature. + * Callers of this function need to pass a char * buffer of size + * X86_CAP_BUF_SIZE. + */ +const char *x86_cap_name(unsigned int bit, char *buf) +{ + unsigned int word =3D bit >> 5; + const char *name =3D NULL; + + if (word < NCAPINTS) + name =3D x86_cap_flags[bit]; + else if (word < NCAPINTS + NBUGINTS) + name =3D x86_bug_flags[bit - 32 * NCAPINTS]; + + if (name) + return name; + + snprintf(buf, X86_CAP_BUF_SIZE, "%u:%u", word, bit & 31); + 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-d= eps.c index 146f6f8b0650..5002f496d095 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -156,24 +156,9 @@ void setup_clear_cpu_cap(unsigned int feature) do_clear_cpu_cap(NULL, feature); } =20 -/* - * Return the feature "name" if available, otherwise return - * the X86_FEATURE_* numerals to make it easier to identify - * the feature. - */ -static const char *x86_feature_name(unsigned int feature, char *buf) -{ - if (x86_cap_flags[feature]) - return x86_cap_flags[feature]; - - snprintf(buf, 16, "%d*32+%2d", feature / 32, feature % 32); - - return buf; -} - void check_cpufeature_deps(struct cpuinfo_x86 *c) { - char feature_buf[16], depends_buf[16]; + char feature_buf[X86_CAP_BUF_SIZE], depends_buf[X86_CAP_BUF_SIZE]; const struct cpuid_dep *d; =20 for (d =3D cpuid_deps; d->feature; d++) { @@ -185,8 +170,8 @@ void check_cpufeature_deps(struct cpuinfo_x86 *c) */ pr_warn_once("x86 CPU feature dependency check failure: CPU%d has '%s' = enabled but '%s' disabled. Kernel might be fine, but no guarantees.\n", smp_processor_id(), - x86_feature_name(d->feature, feature_buf), - x86_feature_name(d->depends, depends_buf)); + x86_cap_name(d->feature, feature_buf), + x86_cap_name(d->depends, depends_buf)); } } } --=20 2.53.0 From nobody Sat Apr 4 07:49:33 2026 Received: from mail-106119.protonmail.ch (mail-106119.protonmail.ch [79.135.106.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EBF043B47E0 for ; Fri, 20 Mar 2026 12:50:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.119 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011033; cv=none; b=Hl84e4Z/gU358bHh4ViYIE7WWx48uX1JrxRgpKmi+5WiKBxGZQ1kJlZRDwv3AxW140L5/DIkSftNS3gf+p/9LeRYmgFI834ZSzBtzaLkm0DhKeVj/ldWOGTBeVfT94J5CPWE/ueh0yEkJuXtwSWxaRelwCabNK9NyY1UE2+7vLc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011033; c=relaxed/simple; bh=42ClJ3mgjFdiqXPJ7+sQawcD/PiBFkaC7lPt56nfUmY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QUu9kFvl5Odpvs3YHCZEkcZiuI6BguVwktK7X2a3ug4IW+7g0bByVBm5HOHuQYhYAoYLoRR2uuBucWYOfnWHQGYWoI13WUPh2o9O/amUYnm7rS3ne73VpG6r3MrKG2hllg2GVvfa5Jxp1OpBYjcZr5inHCvbpYluURCfcsIZZEY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=q2/f7bwp; arc=none smtp.client-ip=79.135.106.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="q2/f7bwp" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774011028; x=1774270228; bh=WyN+SH5fx2qFhOO+ienZswuT99oZzI2AUK4818Nlb7U=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=q2/f7bwpzPA6NNbpcQ8Sv6PEbdjYt7/4abcnC1Hb4y2zzUgbLeqeidcS+5NXwk6SW VZjImW/sUdxrAmXisN4YzM4q0ieP9INuD3sDDLOSYd+fpIA0T6Wd7QNsASMzMmsh3P UhsjUpT2rRjgGdpQG0DhdZLuWeOHl33P1szZLYaRt+beLc9/GBOC30jz/y0fxdGS6c owYPzOOMAnqDNgKsRRRC0kaXlw9eG3Ab7UibcPJzBHp/8lWvUAjfiFKU+70ofsjegp FhAMtTfocu0xS+mXlsoKtZFsX/ZeJDHEf0kJ8cxab8wGom+dRhnGqoIXVPrFjMP3LK BElK9uPIG5xuQ== Date: Fri, 20 Mar 2026 12:50:25 +0000 To: tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, bp@alien8.de, mingo@redhat.com From: Maciej Wieczor-Retman Cc: x86@kernel.org, linux-kernel@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits Message-ID: <7312c9f2feab8aea4612ed9a1841e8c22f5f69b1.1774008873.git.m.wieczorretman@pm.me> In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: 0f9b6bce2a71302bb674e39d149f12f5aedf764a Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman After CPU identification concludes, do a sanity check by comparing the final x86_capability bitmask with the pre-defined required feature bits. Because for_each_set_bit() expects 64-bit values and feature bitmasks are 32-bit use DECLARE_BITMAP() to avoid unaligned memory accesses if NCAPINTS is ever an odd number. Signed-off-by: Maciej Wieczor-Retman --- Changelog v11: - Use DECLARE_BITMAP() on missing[] and recast to a u32 pointer for iterating. Do it to avoid unaligned memory accesses when later using for_each_set_bit() if NCAPINTS is going to ever become an odd number. missing[] was previously an u32 array and for_each_set_bit() works on unsigned long chunks of memory. - Add a paragraph about the above to the patch message. - Remove Peter's acked-by due to more changes. Changelog v10: - Shorten the comment before the sanity check. - cpu -> CPU in the warning. - NCAPINTS << 5 -> NCAPINTS * 32 Changelog v9: - REQUIRED_MASK_INITIALIZER -> REQUIRED_MASK_INIT - Redo the comments. - Fix reverse xmas order. - Inside for_each_set_bit: (void *) -> (unsigned long *). - 16 -> X86_CAP_BUF_SIZE. Changelog v6: - Add Peter's acked-by tag. - Rename patch subject to imperative form. - Add a char buffer to the x86_cap_name() call. arch/x86/kernel/cpu/common.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 0e318f3d56cb..92159a0963c8 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2005,6 +2005,38 @@ const char *x86_cap_name(unsigned int bit, char *buf) return buf; } =20 +/* + * As a sanity check compare the final x86_capability bitmask with the ini= tial + * predefined required feature bits. + */ +static void verify_required_features(const struct cpuinfo_x86 *c) +{ + u32 required_features[NCAPINTS] =3D REQUIRED_MASK_INIT; + DECLARE_BITMAP(missing, NCAPINTS * 32); + char cap_buf[X86_CAP_BUF_SIZE]; + u32 *missing_u32; + unsigned int i; + u32 error =3D 0; + + memset(missing, 0, sizeof(missing)); + missing_u32 =3D (u32 *)missing; + + for (i =3D 0; i < NCAPINTS; i++) { + missing_u32[i] =3D ~c->x86_capability[i] & required_features[i]; + error |=3D missing_u32[i]; + } + + if (!error) + return; + + /* At least one required feature is missing */ + pr_warn("CPU %d: missing required feature(s):", c->cpu_index); + for_each_set_bit(i, missing, NCAPINTS * 32) + pr_cont(" %s", x86_cap_name(i, cap_buf)); + pr_cont("\n"); + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); +} + /* * This does the hard work of actually picking apart the CPU stuff... */ @@ -2134,6 +2166,8 @@ static void identify_cpu(struct cpuinfo_x86 *c) mcheck_cpu_init(c); =20 numa_add_cpu(smp_processor_id()); + + verify_required_features(c); } =20 /* --=20 2.53.0 From nobody Sat Apr 4 07:49:33 2026 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B95F3B6377 for ; Fri, 20 Mar 2026 12:50:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011036; cv=none; b=FPetZJt3SPHMqVTXsovQUuaGq/AhqVkX2MJ36Zdkt+i8u36N7F+pS2x9OnelOlWw9JGPsI3a6UfefcANXwhky+pjJToeB59KpceOUmwrKexAOslMAqiVGRrzZdgr+zbX1a6S5qSwbGAq+EiWqlxGugzsJZZwMddGpRYIYzVWipU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774011036; c=relaxed/simple; bh=P2y3pCUze6MKXYd046eUQgg0kBF67LKL5aGaSMgDczs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Urx+22AGaOToJ9rJ5Zo11nCO7mPq0l/4PJuE60kufe8PLJEdQXtFXObArzLOHo0FByZJ7EkVfWhwgOW7d5KU6MseKPH6ZjQGpks5ZDrL6AJ9mNTg8woo57KHL55GQLKKxOIZf7MGmYDH6lnzuzyZJCwSQaYf/9ck3/1p1NUCwWU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=sGAU0cYz; arc=none smtp.client-ip=185.70.43.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="sGAU0cYz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1774011032; x=1774270232; bh=P2y3pCUze6MKXYd046eUQgg0kBF67LKL5aGaSMgDczs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=sGAU0cYzOFn2KRgVsdK47eCwSk/u4seJsmcHtMDnP/7Nz/PB9jLhk4jdP5cHbpZIG ZCQB65SJ9x49jztjzHclT7JpvQMiKQvvD0VoIseS04FTQJym+gvgjRQjqOa1nWNOXp DprsisYvq38LxdMRuDl8D6kicVfjmS510H2JxE5VluKQDL1Nb0iyGjboWwGd4Ei6lp Y8g1v+LcYFgL4rC9bcM2PN3BifrFPGkeD8utDlagMIjPaUBctlHkChSun4/i1WYUjw Gjehw3DrrtvcQifcGF/FLDeo67HcdhH0ECuONCcWI0LAdJiVes+Dh4yVJ06dTiPcgS pPXlOIa7wtmJw== Date: Fri, 20 Mar 2026 12:50:29 +0000 To: tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, hpa@zytor.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, bp@alien8.de, mingo@redhat.com From: Maciej Wieczor-Retman Cc: x86@kernel.org, linux-kernel@vger.kernel.org, m.wieczorretman@pm.me Subject: [PATCH v11 4/4] x86/cpu: Clear feature bits whose dependencies were cleared Message-ID: In-Reply-To: References: Feedback-ID: 164464600:user:proton X-Pm-Message-ID: f78bb0c989a5e405107772b317573bbf4998fbe6 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maciej Wieczor-Retman After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT, features present in disabled bitmasks are cleared from x86_capability[]. However features that depend on them and are not part of any disabled mask are not cleared by anything. They can trigger the warning in check_cpufeature_deps(), as before both features would show up as enabled even though they weren't. The uncleared features can also still falsely show up in /proc/cpuinfo. Running setup_clear_cpu_cap() on such cases inside check_cpufeature_deps() should guarantee that the cleanup of the leftover bits has to run only once. Afterwards apply_forced_caps() clears the leftover bits from x86_capability[] and the warning inside check_cpufeature_deps() doesn't trigger anymore. Signed-off-by: Maciej Wieczor-Retman --- Changelog v11: - Add this patch to the series. arch/x86/kernel/cpu/cpuid-deps.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-d= eps.c index 5002f496d095..b0f5d3fe6655 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -163,6 +163,16 @@ void check_cpufeature_deps(struct cpuinfo_x86 *c) =20 for (d =3D cpuid_deps; d->feature; d++) { if (cpu_has(c, d->feature) && !cpu_has(c, d->depends)) { + /* + * If the dependency was cleared through the disabled + * bitmasks while the feature wasn't it also needs to be + * cleared. + */ + if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depe= nds)) { + setup_clear_cpu_cap(d->feature); + continue; + } + /* * Only warn about the first unmet dependency on the * first CPU where it is encountered to avoid spamming --=20 2.53.0