Re: [PATCH v4 01/10] x86/bugs: Only log missing retpoline when it's actually the missing mitigation

On Tue, Aug 04, 2026 at 06:56:02PM -0500, Kim Phillips wrote:
> spectre_v2_select_retpoline() unconditionally emits a pr_err when the
> kernel lacks retpoline support before returning SPECTRE_V2_NONE to its
> callers.

Unconditionally? There's an "if" there. :)

> A caller may then select an alternative mitigation, making the "no
> mitigation available!" message alarming and misleading to administrators on
> a system that is actually mitigated.
> 
> Drop the pr_err from the helper and emit it once from
> spectre_v2_update_mitigation().  Guard it on
> !IS_ENABLED(CONFIG_MITIGATION_RETPOLINE) so it only fires when retpoline
> truly cannot be built in,

This is explaining the diff. Doesn't belong in the commit message.

> and restrict it to the cases where retpoline
> was the implied choice: SPECTRE_V2_CMD_FORCE, or SPECTRE_V2_CMD_AUTO
> when should_mitigate_vuln(X86_BUG_SPECTRE_V2) indicates we actually
> intended to mitigate. 

> This avoids the spurious error on a
> CONFIG_MITIGATION_RETPOLINE=n kernel where a caller of
> spectre_v2_select_retpoline() selects an alternative mitigation, leaving
> the system protected while the old message claimed otherwise.

This should be your first sentence. What the issue is.

Which begs the question: why?

Why do we care about a CONFIG_MITIGATION_RETPOLINE=n kernel?

You either disable all mitigations or enable them all (distro kernel) and they
get then configured at boot time. Why would I want to disable RETPOLINE only
but leave spectre v2?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette