public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: ndesaulniers <ndesaulniers@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>, x86 <x86@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	bristot <bristot@redhat.com>, jbaron <jbaron@akamai.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, Nadav Amit <namit@vmware.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH v4 14/18] static_call: Add static_cond_call()
Date: Tue, 5 May 2020 16:27:44 -0400 (EDT)	[thread overview]
Message-ID: <470458191.1021.1588710464160.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <CAKwvOdnLze0e3Vwmb1Xdqwcwe9h6gnAwGnt3ksiNX7ENb_3Y9w@mail.gmail.com>

----- On May 5, 2020, at 3:57 PM, ndesaulniers ndesaulniers@google.com wrote:

> On Tue, May 5, 2020 at 12:00 PM Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> ----- On May 5, 2020, at 2:48 PM, Linus Torvalds torvalds@linux-foundation.org
>> wrote:
>> [...]
>> >
>> > Your initial reaction that "you can't compile away the read and the
>> > test of NULL" was correct, I think.
>>
>> I suspect this pattern of "if (func != NULL) func(...)" could be semantically
>> changed to just invoking an empty function which effectively does nothing.
>> This would remove the need to do a pointer check in the first place. But maybe
>> I'm missing something subtle about why it has not been done in this context.
> 
> Good idea, this eliminates the check: https://godbolt.org/z/Xugo9w
> but you still have an indirect tail call (I think a direct tail call
> is the desired solution?)

Actually, if the goal is to do code patching of the call, I wonder
what makes it OK to "guess" all the call patterns generated by the compiler ?
AFAIU this is not an ABI in any way. For instance, a new compiler version could
choose to add some no-op instructions within this pattern just because it feels
like it.

For static jumps, we worked with the compiler people to add "asm goto ()" so
we could express a jump in assembly which would branch outside of the asm.
Emitting the jump in assembly allows us to control the exact code pattern,
which can then be patched, and the asm goto operands allow the compiler to
be in control of all the allowed branch targets.

I'm again possibly missing something, but it looks like this proposal of static_call()
(especially the static_cond_call part) is trying to just assume the common call
patterns generated by the compilers, and patch those. What is the expected behavior
if a compiler ends up generating unknown code patterns in future versions ?

I would think a more robust approach would be to, again, work with the compiler people
and introduce something like:

asm call ("asm goes here" : : : funcA, funcB, funcC )

which would allow patching the call emitted _in assembly_ between the various
available targets. Bonus points if the compiler can let the asm know whether
it's a standard call or tail-call.

Then once we have that, we can start doing fun stuff like adding a conditional
within the assembly, but I don't see why the conditional should be the same
variable as the actual function pointer: each can be changed independently as
long as the function pointer always points to a "valid" function (not NULL).

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2020-05-05 20:27 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 20:28 [PATCH v4 00/18] Add static_call() Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 01/18] notifier: Fix broken error handling pattern Peter Zijlstra
2020-05-01 23:35   ` Steven Rostedt
2020-05-01 20:28 ` [PATCH v4 02/18] module: Fix up module_notifier return values Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 03/18] module: Properly propagate MODULE_STATE_COMING failure Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 04/18] jump_label,module: Fix module lifetime for __jump_label_mod_text_reserved Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 05/18] compiler.h: Make __ADDRESSABLE() symbol truly unique Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 06/18] static_call: Add basic static call infrastructure Peter Zijlstra
2020-05-05 21:21   ` Josh Poimboeuf
2020-05-01 20:28 ` [PATCH v4 07/18] static_call: Add inline " Peter Zijlstra
2020-05-05 22:10   ` Josh Poimboeuf
2020-05-06 16:15     ` Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 08/18] static_call: Avoid kprobes on inline static_call()s Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 09/18] x86/static_call: Add out-of-line static call implementation Peter Zijlstra
2020-05-06 16:16   ` Peter Zijlstra
2020-05-01 20:28 ` [PATCH v4 10/18] x86/static_call: Add inline static call implementation for x86-64 Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 11/18] static_call: Simple self-test Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 12/18] tracepoint: Optimize using static_call() Peter Zijlstra
2020-05-13  8:48   ` [tracepoint] 01edfaf177: WARNING:at_kernel/static_call.c:#__static_call_update kernel test robot
2020-05-15 17:13     ` Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 13/18] x86/alternatives: Teach text_poke_bp() to emulate RET Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 14/18] static_call: Add static_cond_call() Peter Zijlstra
2020-05-02 13:08   ` Rasmus Villemoes
2020-05-03 12:58     ` Peter Zijlstra
2020-05-04  7:20       ` Rasmus Villemoes
2020-05-04 20:14         ` Peter Zijlstra
2020-05-05  7:50           ` Rasmus Villemoes
2020-05-05  9:38             ` Peter Zijlstra
2020-05-05  9:36           ` Peter Zijlstra
2020-05-05 18:13             ` Nick Desaulniers
2020-05-05 18:27               ` Nick Desaulniers
2020-05-05 18:48                 ` Linus Torvalds
2020-05-05 19:00                   ` Mathieu Desnoyers
2020-05-05 19:57                     ` Nick Desaulniers
2020-05-05 20:27                       ` Mathieu Desnoyers [this message]
2020-05-06 13:55                         ` Peter Zijlstra
2020-05-06 14:01                           ` Mathieu Desnoyers
2020-05-06 16:18                             ` Peter Zijlstra
2020-05-06 13:51               ` Peter Zijlstra
2020-05-06 16:00                 ` Peter Zijlstra
2020-05-06 17:16                 ` Linus Torvalds
2020-05-06 19:57                   ` Andy Lutomirski
2020-05-06 17:24   ` Josh Poimboeuf
2020-05-06 17:58     ` Peter Zijlstra
2020-05-06 18:09       ` Josh Poimboeuf
2020-05-06 18:16         ` Peter Zijlstra
2020-05-08 15:27     ` Peter Zijlstra
2020-05-08 15:47       ` Josh Poimboeuf
2020-05-08 16:17         ` Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 15/18] static_call: Handle tail-calls Peter Zijlstra
2020-05-06 18:10   ` Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 16/18] static_call: Allow early init Peter Zijlstra
2020-05-06 21:15   ` Josh Poimboeuf
2020-05-08 13:31     ` Peter Zijlstra
2020-05-08 14:27       ` Josh Poimboeuf
2020-05-08 15:30         ` Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 17/18] x86/perf, static_call: Optimize x86_pmu methods Peter Zijlstra
2020-05-01 20:29 ` [PATCH v4 18/18] objtool: Clean up elf_write() condition Peter Zijlstra
2020-05-06 17:32 ` [PATCH v4 00/18] Add static_call() Josh Poimboeuf
2020-05-06 18:05   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470458191.1021.1588710464160.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bristot@redhat.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jbaron@akamai.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namit@vmware.com \
    --cc=ndesaulniers@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox