[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1238787e-d97d-f09b-d76d-2df2dc273f4b@rasmusvillemoes.dk>
Date: Sat, 2 May 2020 15:08:00 +0200
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,
pbonzini@...hat.com, mathieu.desnoyers@...icios.com
Subject: Re: [PATCH v4 14/18] static_call: Add static_cond_call()
On 01/05/2020 22.29, Peter Zijlstra wrote:
> Extend the static_call infrastructure to optimize the following common
> pattern:
>
> if (func_ptr)
> func_ptr(args...)
>
> +
> #define static_call(name) __static_call(name)
> +#define static_cond_call(name) (void)__static_call(name)
>
> +
> #define static_call(name) __static_call(name)
> +#define static_cond_call(name) (void)__static_call(name)
>
> +#define static_cond_call(name) \
> + if (STATIC_CALL_KEY(name).func) \
> + ((typeof(STATIC_CALL_TRAMP(name))*)(STATIC_CALL_KEY(name).func))
> +
This addresses neither the READ_ONCE issue nor the fact that, AFAICT,
the semantics of
static_cond_call(foo)(i++)
will depend on CONFIG_HAVE_STATIC_CALL. Also, I'd have appreciated being
cc'ed on new revisions instead of stumbling on it by chance.
Rasmus
Powered by blists - more mailing lists