[PATCH] arm64: stacktrace: fix the usage of ftrace_graph_ret_addr()

[Will Deacon]

On Tue, Jun 18, 2024 at 06:42:54PM +0100, Mark Rutland wrote:
> On Tue, Jun 18, 2024 at 04:23:42PM +0000, Puranjay Mohan wrote:
> > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> > index 6b3258860377..2729faaee4b4 100644
> > --- a/arch/arm64/kernel/stacktrace.c
> > +++ b/arch/arm64/kernel/stacktrace.c
> > @@ -25,6 +25,7 @@
> >   *
> >   * @common:      Common unwind state.
> >   * @task:        The task being unwound.
> > + * @graph_idx:   Used by ftrace_graph_ret_addr() for optimized stack unwinding.
> >   * @kr_cur:      When KRETPROBES is selected, holds the kretprobe instance
> >   *               associated with the most recently encountered replacement lr
> >   *               value.
> > @@ -32,6 +33,7 @@
> >  struct kunwind_state {
> >  	struct unwind_state common;
> >  	struct task_struct *task;
> > +	int graph_idx;
> 
> Minor nit, but could we make that:
> 
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> 	int graph_idx;
> #endif
> 	
> Regardless, this looks good to me, and I've tested it with a few
> stacktrace scenarios including the example from commit:
> 
>   c6d3cd32fd0064af ("arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR")
> 
> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
> Tested-by: Mark Rutland <mark.rutland at arm.com>
> 
> Steve, what's your plan for merging the ftrace bits, and how should we
> stage this relative to that? e.g. would it make sense for this to go
> through the ftrace tree along with those changes so that this doesn't
> end up transiently broken during the merge window?
> 
> Catalin, Will, do you have any preference?

I think it makes most sense if this patch travels together with
29c1c24a2707 ("function_graph: Fix up ftrace_graph_ret_addr()"), so that
would be via Steve's tree. In which case:

Acked-by: Will Deacon <will at kernel.org>

Will