Re: [PATCH 1/2] x86: Don't clear X86_BUG_F00F before setting it

[Sohil Mehta <sohil.mehta@intel.com>]

On 2/16/2026 2:43 AM, Richard Weinberger wrote:
> On x86 SMP systems with the F00F bug is present the following
> warning occurs for each application processor:
> 
> [    0.013122] ------------[ cut here ]------------
> [    0.013122] WARNING: arch/x86/kernel/cpu/cpuid-deps.c:126 at do_clear_cpu_cap+0xb4/0x110, CPU#1: swapper/1/0
> [    0.013122] Modules linked in:
> [    0.013122] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.19.0-10445-g0f2acd3148e0 #379 PREEMPT(full)
> [    0.013122] Hardware name:  , BIOS 4.51 PG 04/03/97
> [    0.013122] EIP: do_clear_cpu_cap+0xb4/0x110
> [    0.013122] Code: 08 83 c7 08 85 c0 75 ce 84 d2 75 c2 8b 45 f0 64 2b 05 08 80 af c4 75 64 83 c4 68 5b 5e 5f 5d c3 8b 0d 78 7a a1 c4 85 c9 74 83 <0f> 0b e9 7c ff ff ff 2e 8d 74 26 00 b8 20 79 a1 c4 89 55 8c e8 33
> [    0.013122] EAX: 00000000 EBX: c1143ed8 ECX: 00000001 EDX: 000002c0
> [    0.013122] ESI: c7ee8060 EDI: c1143f38 EBP: c1143f48 ESP: c1143ed4
> [    0.013122] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00210002
> [    0.013122] CR0: 80050033 CR2: 00000000 CR3: 04b15000 CR4: 00000010
> [    0.013122] Call Trace:
> [    0.013122]  clear_cpu_cap+0x8/0x10
> [    0.013122]  init_intel+0x1b/0x4b0
> [    0.013122]  identify_cpu+0x154/0x750
> [    0.013122]  identify_secondary_cpu+0x3d/0x90
> [    0.013122]  start_secondary+0x6b/0xf0
> [    0.013122]  startup_32_smp+0x151/0x160
> [    0.013122] ---[ end trace 0000000000000000 ]---
> 

This trace should probably be trimmed. The function call list is likely
more than enough.

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-messages


> Commit ee8962082a44 ("x86/alternatives: Catch late X86_FEATURE modifiers") introduced the warning
> to catch changes to x86 features after alternatives have been applied.
> 
> Since the X86_BUG_F00F CPU feature is first cleared in
> intel_workarounds() and then set for the affected families, the feature
> flags are unnecessarily modified. On systems where the F00F bug is
> actually present, clearing the flag first triggers the warning.
> 

It might be useful to explicitly say that these order of events work
fine on the BSP but only cause problems on APs.

> Fix this by not clearing the flag first. Clearing it first is relict from
> commit e2604b49e8a8 ("x86, cpu: Convert F00F bug detection").
> 

Yeah, I couldn't find any historical reason to clear the bug first and
then set it. Not a strong preference but shouldn't above be set the
"Fixes" commit instead of below?

> Fixes: ee8962082a44 ("x86/alternatives: Catch late X86_FEATURE modifiers")
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  arch/x86/kernel/cpu/intel.c | 1 -
>  1 file changed, 1 deletion(-)
> 

The code change looks good to me.
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>

> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 646ff33c4651..73f6bf182333 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -394,7 +394,6 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>  	 * system. Announce that the fault handler will be checking for it.
>  	 * The Quark is also family 5, but does not have the same bug.
>  	 */
> -	clear_cpu_bug(c, X86_BUG_F00F);
>  	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
>  		static int f00f_workaround_enabled;
>