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

[Peter Zijlstra <peterz@infradead.org>]

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.

> 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 :-)

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*