Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, 3 Mar 2025 at 01:02, tip-bot2 for Josh Poimboeuf
> <tip-bot2@xxxxxxxxxxxxx> wrote:
> >
> > x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers
> >
> > With frame pointers enabled, ASM_CALL_CONSTRAINT is used in an inline
> > asm statement with a call instruction to force the compiler to set up
> > the frame pointer before doing the call.
> >
> > Without frame pointers, no such constraint is needed.  Make it
> > conditional on frame pointers.
> 
> Can we please explain *why* this is done?
> 
> It may not be required, but it makes the source code uglier and adds a
> conditional. What's the advantage of adding this extra logic?
> 
> I'm sure there is some reason for this change, but that reason should
> be explained.
> 
> Because "we don't need it" cuts both ways. Maybe we don't need the
> ASM_CALL_CONSTRAINT, but it also didn't use to hurt us.
> 
> The problems seems entirely caused by the change to use a strictly
> inferior version of ASM_CALL_CONSTRAINT.
> 
> Is there really no better option? Because the new ASM_CALL_CONSTRAINT
> seems actively horrendous.

So Josh forgot to Cc: lkml in this 5-patch series:

63852     Mar 02 Josh Poimboeuf     | [PATCH 0/5] x86: Fix ASM_CALL_CONSTRAINT for Clang 19 and disable it for ORC
63853     Mar 02 Josh Poimboeuf     | ├─>[PATCH 1/5] KVM: VMX: Use named operands in inline asm
63855     Mar 02 Josh Poimboeuf     | ├─>[PATCH 2/5] x86/hyperv: Use named operands in inline asm
63856     Mar 02 Josh Poimboeuf     | ├─>[PATCH 3/5] x86/alternative: Simplify alternative_call() interface
63857     Mar 02 Josh Poimboeuf     | ├─>[PATCH 4/5] x86: Fix ASM_CALL_CONSTRAINT for Clang 19 + KCOV + KMSAN
63858     Mar 02 Josh Poimboeuf     | ├─>[PATCH 5/5] x86: Make ASM_CALL_CONSTRAINT conditional on frame pointers

... which omission I tried to fix in the commits by adding Cc: lkml - 
but which made the discussion unthreaded on Lore ... a mistake I won't 
repeat.

This reply of yours is for patch 5/5 which is arguably out of context 
in isolation, while the main justification for changing 
ASM_CALL_CONSTRAINT is in 4/5 (a Clang 19 code generation quirk to fix 
a warning) - see attached it below.

The full 5-patch series in -next is:

  cccc85ea4032 KVM: VMX: Use named operands in inline asm
  2668d7b4aff8 x86/hyperv: Use named operands in inline asm
  1edd623ccaaf x86/alternatives: Simplify alternative_call() interface
  96092b7552d9 x86/asm: Fix ASM_CALL_CONSTRAINT for Clang 19 + KCOV + KMSAN
  e5ff90b179d4 x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

I bounced you the key emails, but I'm not sure that helps much.

I'll avoid this situation in the future, Cc:lkml works well for 
individual patches and I used it in the past, but it loses context in 
the series-submission case.

Thanks,

	Ingo

===============================>