Re: [PATCH v3 4/5] x86/cpu: Move 32-bit SEP setup into identify_cpu()

[bot+bpf-ci]

> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 2b2a4c40ef76c..83d613d07997e 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -2126,6 +2126,9 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>  	mcheck_cpu_init(c);
>
>  	numa_add_cpu(smp_processor_id());
> +
> +	if (IS_ENABLED(CONFIG_X86_32))
> +		enable_sep_cpu();
>  }

Does using IS_ENABLED() here comply with the kernel coding style?

Looking at enable_sep_cpu(), it's declared in arch/x86/include/asm/processor.h
as `extern void enable_sep_cpu(void);` but the definition only exists inside
`#ifdef CONFIG_X86_32` in this file (arch/x86/kernel/cpu/common.c:2138-2160),
with no `#else` stub for 64-bit builds.

Documentation/process/coding-style.rst explains when IS_ENABLED() can and
cannot be used:

    The compiler will constant-fold the conditional away ... However, this
    approach still allows the C compiler to see the code inside the block,
    and check it for correctness (syntax, types, symbol references, etc).
    Thus, you still have to use an #ifdef if the code inside the block
    references symbols that will not exist if the condition is not met.

The symbol enable_sep_cpu() won't exist in 64-bit builds, so this seems to
be exactly the case the documentation warns against.

In practice this links correctly because the kernel is always built at -O2
or -Os, and both GCC and Clang will drop the untaken arm of a constant if.
But it depends on the optimizer eliminating the dead code before the linker
sees it.

A survey of other `if (IS_ENABLED(CONFIG_X86_32))` sites in arch/x86 shows
that they all reference symbols that exist in both builds, making this the
first site to rely on dead-code elimination for link correctness.

Would it be more correct to either keep the `#ifdef CONFIG_X86_32` around
this call, or add a static inline stub for the 64-bit case in processor.h?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35285131592