linux-kernel - Re: [PATCH v4 1/2] ftrace: cleanup ftrace_graph

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yl6f0XKoRxNhgGPv@FVFF77S0Q05N>
Date:   Tue, 19 Apr 2022 12:41:05 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Chengming Zhou <zhouchengming@...edance.com>
Cc:     rostedt@...dmis.org, mingo@...hat.com, catalin.marinas@....com,
        will@...nel.org, tglx@...utronix.de, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        broonie@...nel.org, ardb@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        duanxiongchun@...edance.com, songmuchun@...edance.com
Subject: Re: [PATCH v4 1/2] ftrace: cleanup ftrace_graph_caller enable and
 disable

On Sat, Apr 09, 2022 at 11:35:53PM +0800, Chengming Zhou wrote:
> The ftrace_[enable,disable]_ftrace_graph_caller() are used to do
> special hooks for graph tracer, which are not needed on some ARCHs
> that use graph_ops:func function to install return_hooker.
> 
> So introduce the weak version in ftrace core code to cleanup
> in x86.
> 
> Signed-off-by: Chengming Zhou <zhouchengming@...edance.com>
> ---
> v4:
>  - put weak ftrace_enable,disable_ftrace_graph_caller() in
>    fgraph.c instead of ftrace.c as suggested by Steve.
> 
> v3:
>  - consolidate two #if into a single #if, suggested by Steve. Thanks.
> ---
>  arch/x86/kernel/ftrace.c | 17 ++---------------
>  kernel/trace/fgraph.c    | 18 ++++++++++++++++++
>  2 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 1e31c7d21597..b09d73c2ba89 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -579,9 +579,7 @@ void arch_ftrace_trampoline_free(struct ftrace_ops *ops)
>  
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  
> -#ifdef CONFIG_DYNAMIC_FTRACE
> -
> -#ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
> +#if defined(CONFIG_DYNAMIC_FTRACE) && !defined(CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS)
>  extern void ftrace_graph_call(void);
>  static const char *ftrace_jmp_replace(unsigned long ip, unsigned long addr)
>  {
> @@ -610,18 +608,7 @@ int ftrace_disable_ftrace_graph_caller(void)
>  
>  	return ftrace_mod_jmp(ip, &ftrace_stub);
>  }
> -#else /* !CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS */
> -int ftrace_enable_ftrace_graph_caller(void)
> -{
> -	return 0;
> -}
> -
> -int ftrace_disable_ftrace_graph_caller(void)
> -{
> -	return 0;
> -}
> -#endif /* CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS */
> -#endif /* !CONFIG_DYNAMIC_FTRACE */
> +#endif /* CONFIG_DYNAMIC_FTRACE && !CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS */
>  
>  /*
>   * Hook the return address and push it in the stack of return addrs
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index 8f4fb328133a..289311680c29 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -30,6 +30,24 @@ int ftrace_graph_active;
>  /* Both enabled by default (can be cleared by function_graph tracer flags */
>  static bool fgraph_sleep_time = true;
>  
> +/*
> + * archs can override this function if they must do something
> + * to enable hook for graph tracer.
> + */
> +int __weak ftrace_enable_ftrace_graph_caller(void)
> +{
> +	return 0;
> +}
> +
> +/*
> + * archs can override this function if they must do something
> + * to disable hook for graph tracer.
> + */
> +int __weak ftrace_disable_ftrace_graph_caller(void)
> +{
> +	return 0;
> +}

IIUC an arch should either:

* Have ftrace_graph_call()

* Have both ftrace_enable_ftrace_graph_caller() and
  ftrace_disable_ftrace_graph_caller()

... and I can't think of a reason an arch would need both ftrace_graph_call()
*and* the enable/disable functions.

Given that, could we drop the `__weak` and place these within ifdeffery, i.e.
make the above:

| #ifndef ftrace_graph_call
| int ftrace_enable_ftrace_graph_caller(void) { return 0; }
| int ftrace_disable_ftrace_graph_caller(void) { return 0; }
| #endif /* ftrace_graph_call *. 

That way we'd catch cases when:

* An architecture meant to provide one of these functions, but forgot (e.g. the
  name got typo'd)

* An architecture provides an unnecessary implementation of either of these
  functions.

Regardless, this looks ok to me. Steve, are you happy with this? I suspect we'd
need to take this via the arm64 tree with the next patch, so we'd need your Ack.

Thanks,
Mark.

> +
>  /**
>   * ftrace_graph_stop - set to permanently disable function graph tracing
>   *
> -- 
> 2.35.1
>