[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10ef25bf-87df-6917-1d50-c29ece442766@rasmusvillemoes.dk>
Date: Fri, 27 Mar 2020 00:37:35 +0100
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Peter Zijlstra <peterz@...radead.org>, x86@...nel.org
Cc: 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, jpoimboe@...hat.com
Subject: Re: [RESEND][PATCH v3 14/17] static_call: Add static_cond_call()
On 24/03/2020 14.56, Peter Zijlstra wrote:
> Extend the static_call infrastructure to optimize the following common
> pattern:
>
> if (func_ptr)
> func_ptr(args...)
>
> +#define DEFINE_STATIC_COND_CALL(name, _func) \
> + DECLARE_STATIC_CALL(name, _func); \
> + struct static_call_key STATIC_CALL_NAME(name) = { \
> + .func = NULL, \
> + }
> +
> #define static_call(name) \
> ((typeof(STATIC_CALL_TRAMP(name))*)(STATIC_CALL_NAME(name).func))
>
> +#define static_cond_call(name) \
> + if (STATIC_CALL_NAME(name).func) \
> + ((typeof(STATIC_CALL_TRAMP(name))*)(STATIC_CALL_NAME(name).func))
> +
What, apart from fear of being ridiculed by kernel folks, prevents the
compiler from reloading STATIC_CALL_NAME(name).func ? IOW, doesn't this
want a READ_ONCE somewhere?
And please remind me, what is the consensus for sizeof(long) loads: does
static_call() need load-tearing protection or not?
Rasmus
Powered by blists - more mailing lists