Re: [PATCH] kernel/trace: Remove function callback casts

[Oscar Carter <oscar.carter@gmx.com>]

On Wed, Jun 17, 2020 at 04:28:00PM -0400, Steven Rostedt wrote:
> On Mon, 15 Jun 2020 16:22:45 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > As I was saying. This typecast is being paranoid, as archs will call
> > the ftrace_ops_list_func directly, and only pass in two parameters.
> >
> > Now one way around this is to instead of having the typecast, I could
> > use linker magic to create another function that I can define without
> > the typecast to get the same effect. Similar to what I did in commit:
> >
> > 46f9469247c6f ("ftrace: Rename ftrace_graph_stub to ftrace_stub_graph")
>
> Would something like this work for you?
>
> -- Steve
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index db600ef218d7..120babd9ba44 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -145,13 +145,18 @@
>   * Need to also make ftrace_stub_graph point to ftrace_stub
>   * so that the same stub location may have different protocols
>   * and not mess up with C verifiers.
> + *
> + * ftrace_ops_list_func will be defined as arch_ftrace_ops_list_func
> + * as some archs will have a different prototype for that function
> + * but ftrace_ops_list_func() will have a single prototype.
>   */
>  #define MCOUNT_REC()	. = ALIGN(8);				\
>  			__start_mcount_loc = .;			\
>  			KEEP(*(__mcount_loc))			\
>  			KEEP(*(__patchable_function_entries))	\
>  			__stop_mcount_loc = .;			\
> -			ftrace_stub_graph = ftrace_stub;
> +			ftrace_stub_graph = ftrace_stub;	\
> +			ftrace_ops_list_func = arch_ftrace_ops_list_func;
>  #else
>  # ifdef CONFIG_FUNCTION_TRACER
>  #  define MCOUNT_REC()	ftrace_stub_graph = ftrace_stub;
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index f060838e9cbb..b775d399026e 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -119,14 +119,9 @@ struct ftrace_ops __rcu *ftrace_ops_list __read_mostly = &ftrace_list_end;
>  ftrace_func_t ftrace_trace_function __read_mostly = ftrace_stub;
>  struct ftrace_ops global_ops;
>
> -#if ARCH_SUPPORTS_FTRACE_OPS
> -static void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
> -				 struct ftrace_ops *op, struct pt_regs *regs);
> -#else
> -/* See comment below, where ftrace_ops_list_func is defined */
> -static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip);
> -#define ftrace_ops_list_func ((ftrace_func_t)ftrace_ops_no_ops)
> -#endif
> +/* Defined by vmlinux.lds.h see the commment above arch_ftrace_ops_list_func for details */
> +void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
> +			  struct ftrace_ops *op, struct pt_regs *regs);
>
>  static inline void ftrace_ops_init(struct ftrace_ops *ops)
>  {
> @@ -6859,21 +6854,23 @@ __ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
>   * Note, CONFIG_DYNAMIC_FTRACE_WITH_REGS expects a full regs to be saved.
>   * An architecture can pass partial regs with ftrace_ops and still
>   * set the ARCH_SUPPORTS_FTRACE_OPS.
> + *
> + * In vmlinux.lds.h, ftrace_ops_list_func() is defined to be
> + * arch_ftrace_ops_list_func.
>   */
>  #if ARCH_SUPPORTS_FTRACE_OPS
> -static void ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
> -				 struct ftrace_ops *op, struct pt_regs *regs)
> +void arch_ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip,
> +			       struct ftrace_ops *op, struct pt_regs *regs)
>  {
>  	__ftrace_ops_list_func(ip, parent_ip, NULL, regs);
>  }
> -NOKPROBE_SYMBOL(ftrace_ops_list_func);
>  #else
> -static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip)
> +void arch_ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip)
>  {
>  	__ftrace_ops_list_func(ip, parent_ip, NULL, NULL);
>  }
> -NOKPROBE_SYMBOL(ftrace_ops_no_ops);
>  #endif
> +NOKPROBE_SYMBOL(arch_ftrace_ops_list_func);
>
>  /*
>   * If there's only one function registered but it does not support

Thanks for your work and the proper patch sent [1].
I will follow the thread to see if I can help.

[1] https://lore.kernel.org/lkml/20200617165616.52241bde@oasis.local.home/

Regards,
Oscar Carter