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

[Kim Phillips]

On 8/4/26 7:44 PM, Borislav Petkov wrote:
> 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. :)

There's a "when" in there, too:

...unconditionally (emits a pr_err when the kernel lacks retpoline support) before...

So it's saying there are no additional conditions than
!IS_ENABLED(CONFIG_MITIGATION_RETPOLINE), when there should be
(which this patch adds).

> > 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.

Ok

> > 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.

I'll see about rewording the commit text according to this and all your
above comments in the next version.

> 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?
This patch corrects code that already cares about RETPOLINE=n kernels, but
it's also useful if you know all the target systems for a RETPOLINE=n config have
alternatives to RETPOLINE, such as {,e,Auto}IBRS.  This will become more and more
true as time goes by.

Thanks,

Kim