On Fri, Dec 07, 2018 at 04:06:32PM +0000, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
> in the out-of-line implementation, it appears that static_call_update()
> never alters key->func. Am I right in thinking that this should be
> fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
> arch_static_call_transform() on line 159 of include/linux/static_call.h?
Yes, you're right about both bugs in the out-of-line case: key->func
needs to be written, and __static_call_update() needs to be called by
static_call_update. I was so focused on getting the inline case working
that I overlooked those.
> Some background (why does key->func matter for the
> CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
> combining these static calls with the 'indirect call wrappers' notion
> that Paolo Abeni has been working on [1], using runtime instrumentation
> to determine a list of potential callees. (This allows us to cope with
> cases where the callees are in modules, or where different workloads may
> use different sets of callees for a given call site, neither of which is
> handled by Paolo's approach).
> The core of my design looks something like:
>
> static int dynamic_call_xyz(int (*func)(some_args), some_args)
> {
> if (func == dynamic_call_xyz_1.func)
> return static_call(dynamic_call_xyz_1, some_args);
> if (func == dynamic_call_xyz_2.func)
> return static_call(dynamic_call_xyz_2, some_args);
> return (*func)(some_args);
> }
>
> albeit with a bunch of extra (and currently rather ugly) stuff to collect
> the statistics needed to decide what to put in the static call keys, and
> mechanisms (RCU in my current case) to ensure that the static call isn't
> changed between checking its .func and actually calling it.
>
> -Ed
>
> PS: not on list, please keep me in CC.
>
> [1] https://lwn.net/Articles/773985/
Thanks, this sounds very interesting. Adding Nadav to CC, as he has
been looking at a different approach to solving the same problem:
https://lkml.kernel.org/r/20181018005420.82993-1-na...@vmware.com
--
Josh
