[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200506172455.ho5em2mtzn7qqfjl@treble>
Date: Wed, 6 May 2020 12:24:55 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, rostedt@...dmis.org,
mhiramat@...nel.org, bristot@...hat.com, jbaron@...mai.com,
torvalds@...ux-foundation.org, tglx@...utronix.de,
mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
ard.biesheuvel@...aro.org, pbonzini@...hat.com,
mathieu.desnoyers@...icios.com
Subject: Re: [PATCH v4 14/18] static_call: Add static_cond_call()
On Fri, May 01, 2020 at 10:29:03PM +0200, Peter Zijlstra wrote:
> +++ b/arch/x86/include/asm/static_call.h
> @@ -30,4 +30,14 @@
> ".size " STATIC_CALL_TRAMP_STR(name) ", . - " STATIC_CALL_TRAMP_STR(name) " \n" \
> ".popsection \n")
>
> +#define ARCH_DEFINE_STATIC_CALL_RETTRAMP(name) \
> + asm(".pushsection .static_call.text, \"ax\" \n" \
> + ".align 4 \n" \
> + ".globl " STATIC_CALL_TRAMP_STR(name) " \n" \
> + STATIC_CALL_TRAMP_STR(name) ": \n" \
> + " ret; nop; nop; nop; nop; \n" \
> + ".type " STATIC_CALL_TRAMP_STR(name) ", @function \n" \
> + ".size " STATIC_CALL_TRAMP_STR(name) ", . - " STATIC_CALL_TRAMP_STR(name) " \n" \
> + ".popsection \n")
> +
The boilerplate in these two trampoline macros is identical except for
the actual instructions, maybe there could be a shared
__ARCH_DEFINE_STATIC_CALL_TRAMP(name, insns) macro which does most of
the dirty work.
> #endif /* _ASM_STATIC_CALL_H */
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -4,19 +4,41 @@
> #include <linux/bug.h>
> #include <asm/text-patching.h>
>
> -static void __static_call_transform(void *insn, u8 opcode, void *func)
> +enum insn_type {
> + call = 0, /* site call */
> + nop = 1, /* site cond-call */
> + jmp = 2, /* tramp / site tail-call */
> + ret = 3, /* tramp / site cond-tail-call */
> +};
The lowercase enums threw me for a loop, I thought they were variables a
few times. Starting a new enum trend? :-)
> void arch_static_call_transform(void *site, void *tramp, void *func)
> @@ -24,10 +46,10 @@ void arch_static_call_transform(void *si
> mutex_lock(&text_mutex);
>
> if (tramp)
> - __static_call_transform(tramp, JMP32_INSN_OPCODE, func);
> + __static_call_transform(tramp, jmp + !func, func);
>
> if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE) && site)
> - __static_call_transform(site, CALL_INSN_OPCODE, func);
> + __static_call_transform(site, !func, func);
Clever enum math, but probably more robust to be ignorant of the values:
if (tramp)
__static_call_transform(tramp, func ? jmp : ret, func);
if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE) && site)
__static_call_transform(site, func ? call : nop, func);
> +++ b/include/linux/static_call.h
> @@ -16,7 +16,9 @@
> *
> * DECLARE_STATIC_CALL(name, func);
> * DEFINE_STATIC_CALL(name, func);
> + * DEFINE_STATIC_COND_CALL(name, typename);
> * static_call(name)(args...);
> + * static_cond_call(name)(args...)
> * static_call_update(name, func);
Missing semicolon, also an updated description/example would be useful.
On that note, what do you think about tweaking the naming from
DEFINE_STATIC_COND_CALL(name, typename);
static_cond_call(name)(args...);
to
DEFINE_STATIC_CALL_NO_FUNC(name, typename);
static_call_if_func(name)(args...);
?
Seems clearer to me. They're still STATIC_CALLs, so it seems logical to
keep those two words together. And NO_FUNC clarifies the initialized
value.
Similarly RETTRAMP could be ARCH_DEFINE_STATIC_CALL_NO_FUNC.
--
Josh
Powered by blists - more mailing lists