Re: [PATCH v2 0/4] Static calls

[Josh Poimboeuf]

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-namit@xxxxxxxxxx

-- 
Josh