Re: [PATCH 8/8] x86/alternative: Convert alternatives to assembler macros

[Josh Poimboeuf]

On Wed, Dec 10, 2025 at 10:16:45AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 09, 2025 at 05:15:06PM -0800, Josh Poimboeuf wrote:
> 
> > Ok, so while the syntax itself is nested, the underlying behavior is
> > just stacking alternatives together, like ALTERNATIVE_2 and _3 already
> > do, correct?
> 
> Yup.
> 
> > While it's clever that the current implementation allows that kind of
> > nested syntax, it seems dangerous.  I don't see anything preventing the
> > inner ALTERNATIVE from being placed in the middle of the outer
> > ALTERNATIVE's original instructions, or anywhere in the outer's
> > replacement code.
> > 
> > It would be really easy to introduce CALL_NOSPEC in the middle of a
> > group of instructions in an ALTERNATIVE without realizing that you're
> > likely introducing some subtle or not-so-subtle bug on x86-32, which
> > just happens to hide an ALTERNATIVE_2 inside the CALL_NOSPEC...
> 
> I think I made objtool complain in that case, but I'm not sure.

I do see some checks there.  I'm not quite convinced all the edge cases
are covered.

> > The gas macro doesn't give you the leeway to make that mistake, so you'd
> > have to restructure the code slightly to make it fit into a proper
> > ALTERNATIVE_3.  Which is less magical and more clear, so that seems like
> > a good thing.
> 
> Perhaps, I'm not really a fan of the ALTERNATIVE_n() macros much. I
> think writing the nested ALTERNATIVE() form is actually more readable.
> But perhaps I'm the crazy one -- wouldn't be the first time :-)

The nesting might be more readable, but it feels like syntax sugar in a
way that's a conceptual mismatch compared to how the alternatives are
actually applied.

> Anyway, seeing how its not actually used, and I've since solved the case
> that gave rise to all this completely differently, perhaps I should just
> shut up and let you do the conversion.
> 
> I mean, we will have to do ALTERNATIVE_4() at some point, and it will be
> glorious... *sigh*

Well, at least this makes it a unified implementation so the ugly is
only confined to a single place :-)

-- 
Josh