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

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