arch/x86/kernel/cpu/bugs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
When the kernel lacks retpoline support, spectre_v2_select_retpoline()
emits
"Kernel not compiled with retpoline; no mitigation available!"
before returning SPECTRE_V2_NONE to its callers. SPECTRE_V2_NONE is not
the final answer, though: spectre_v2_update_mitigation() runs afterwards
and can still upgrade the mitigation.
On an Intel CPU affected by RETBleed, built with
CONFIG_MITIGATION_IBRS_ENTRY=y and CONFIG_MITIGATION_RETPOLINE=n, and
booted with spectre_v2=auto, retbleed_select_mitigation() picks
RETBLEED_MITIGATION_IBRS, and spectre_v2_update_mitigation() then promotes
SPECTRE_V2_NONE to SPECTRE_V2_IBRS. The boot log claims no mitigation is
available immediately before reporting "Spectre V2 : Mitigation: IBRS",
and sysfs reports the machine as mitigated. The message is alarming and
simply wrong.
Drop "no mitigation available!" because the final mitigation state is
printed afterwards in spectre_v2_update_mitigation() anyway.
Suggested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Fixes: 480e803dacf8 ("x86/bugs: Restructure spectre_v2 mitigation")
Cc: stable@kernel.org
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Assisted-by: ClaudeCode:claude-opus-4-7
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 56eac5611c31..5a0533a41d30 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1957,7 +1957,7 @@ early_param("spectre_v2", spectre_v2_parse_cmdline);
static enum spectre_v2_mitigation __init spectre_v2_select_retpoline(void)
{
if (!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE)) {
- pr_err("Kernel not compiled with retpoline; no mitigation available!");
+ pr_err("Kernel not compiled with retpoline");
return SPECTRE_V2_NONE;
}
--
2.43.0
On Mon, Aug 31, 2026 at 04:09:16PM -0500, Kim Phillips wrote:
> When the kernel lacks retpoline support, spectre_v2_select_retpoline()
> emits
>
> "Kernel not compiled with retpoline; no mitigation available!"
>
> before returning SPECTRE_V2_NONE to its callers. SPECTRE_V2_NONE is not
> the final answer, though: spectre_v2_update_mitigation() runs afterwards
> and can still upgrade the mitigation.
>
> On an Intel CPU affected by RETBleed, built with
> CONFIG_MITIGATION_IBRS_ENTRY=y and CONFIG_MITIGATION_RETPOLINE=n, and
> booted with spectre_v2=auto, retbleed_select_mitigation() picks
> RETBLEED_MITIGATION_IBRS, and spectre_v2_update_mitigation() then promotes
> SPECTRE_V2_NONE to SPECTRE_V2_IBRS. The boot log claims no mitigation is
> available immediately before reporting "Spectre V2 : Mitigation: IBRS",
> and sysfs reports the machine as mitigated. The message is alarming and
> simply wrong.
>
> Drop "no mitigation available!" because the final mitigation state is
> printed afterwards in spectre_v2_update_mitigation() anyway.
>
> Suggested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Fixes: 480e803dacf8 ("x86/bugs: Restructure spectre_v2 mitigation")
> Cc: stable@kernel.org
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
© 2016 - 2026 Red Hat, Inc.