Re: [PATCH v3 05/35] x86/bugs: Restructure taa mitigation

Josh Poimboeuf
2025-02-11T19:17:34Z

On Tue, Feb 11, 2025 at 05:17:15PM +0000, Kaplan, David wrote:
> > On Wed, Jan 08, 2025 at 02:24:45PM -0600, David Kaplan wrote:
> > > @@ -400,48 +402,71 @@ static void __init taa_select_mitigation(void)
> > > return;
> > > }
> > >
> > > - if (cpu_mitigations_off()) {
> > > + if (cpu_mitigations_off())
> > > taa_mitigation = TAA_MITIGATION_OFF;
> > > - return;
> > > - }
> > >
> > > /*
> > > * TAA mitigation via VERW is turned off if both
> > > * tsx_async_abort=off and mds=off are specified.
> > > + *
> > > + * MDS mitigation will be checked in taa_update_mitigation().
> > > */
> > > - if (taa_mitigation == TAA_MITIGATION_OFF &&
> > > - mds_mitigation == MDS_MITIGATION_OFF)
> > > + if (taa_mitigation == TAA_MITIGATION_OFF)
> > > return;
> >
> > This check seems rather pointless, the only thing after this is the
> > TAA_MITIGATION_AUTO check.
>
> True, and it can be removed. But in patch 4 in the mds logic you did suggest having an explicit return to make it clear that none of the later conditions applied. I'm not sure I feel strongly either way, but I'd like to be consistent.

Let me try to clarify:

- If it's already doing the conditional for another reason, then
adding in the return makes sense:

if (condition) {
do_something;
/* all actions related to condition are done */
return;
}

- Or, if it's adding a condition+return to avoid having to explicitly
check for !condition later, that also makes sense.

if (condition)
return;

/* assume !condition */
...

- But adding condition+return, when there's only one condition
remaining in the function, which already implicitly excludes the
original condition, that just adds code for no reason.

/* this has no purpose */
if (condition)
return;

if (!condition && condition2)
do_something;

return;

--
Josh