linux-kernel - Re: [for-linus][PATCH 3/3] ftrace/microblaze: Do not find "true

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: <20241213120043.3368c7b4@gandalf.local.home>
Date: Fri, 13 Dec 2024 12:00:43 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Michal Simek <monstr@...str.eu>
Cc: linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [for-linus][PATCH 3/3] ftrace/microblaze: Do not find
 "true_parent" for return address

On Fri, 13 Dec 2024 16:39:29 +0100
Michal Simek <monstr@...str.eu> wrote:

> On 12/13/24 16:26, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@...dmis.org>
> > 
> > When function tracing and function graph tracing are both enabled (in
> > different instances)   
> 
> What does this mean different instances? Two processes or two cores?

Trace instances:

 # mkdir /sys/kernel/tracing/instances/foo
 # echo function > /sys/kernel/tracing/instances/foo/current_tracer

 # mkdir /sys/kernel/tracing/instances/bar
 # echo function_graph > /sys/kernel/tracing/instances/bar/current_tracer

> 
> 
> the "parent" of some of the function tracing events
> > is "return_to_handler" which is the trampoline used by function graph
> > tracing. To fix this, ftrace_get_true_parent_ip() was introduced that
> > returns the "true" parent ip instead of the trampoline.
> > 
> > To do this, the ftrace_regs_get_stack_pointer() is used, which uses
> > kernel_stack_pointer(). The problem is that microblaze does not implement
> > kerenl_stack_pointer() so when function graph tracing is enabled, the
> > build fails.
> > 
> > Modify the #ifdef check to the code around ftrace_get_true_parent_ip() to
> > include !defined(CONFIG_MICROBLAZE) which will default it to just return
> > the parent ip passed in, which may still be the ip of the function garph  
> 
> here is typo.

Oops, thanks!

> 
> > trampoline.
> > 
> > Cc: Masami Hiramatsu <mhiramat@...nel.org>
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> > Cc: Al Viro <viro@...IV.linux.org.uk>
> > Cc: Michal Simek <monstr@...str.eu>
> > Link: https://lore.kernel.org/20241211153634.69c75afa@batman.local.home
> > Fixes: 60b1f578b578 ("ftrace: Get the true parent ip for function tracer")
> > Reported-by: Al Viro <viro@...iv.linux.org.uk>
> > Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> > ---
> >   kernel/trace/trace_functions.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> > index 74c353164ca1..a75d107a45f8 100644
> > --- a/kernel/trace/trace_functions.c
> > +++ b/kernel/trace/trace_functions.c
> > @@ -176,7 +176,8 @@ static void function_trace_start(struct trace_array *tr)
> >   	tracing_reset_online_cpus(&tr->array_buffer);
> >   }
> >   
> > -#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > +/* Microblaze currently doesn't implement kernel_stack_pointer() */  
> 
> Does it mean that this function should depends on ARCH_HAS_CURRENT_STACK_POINTER 
> instead of name the architecture?

Hmm, I was looking for a more generic option and didn't find one. I don't
think I looked well enough as that could be what we want. Let me check.

I'll drop this patch for now then.

> 
> 
> > +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) && !defined(CONFIG_MICROBLAZE)
> >   static __always_inline unsigned long
> >   function_get_true_parent_ip(unsigned long parent_ip, struct ftrace_regs *fregs)
> >   {  
> 
> Thanks,
> Michal
> 

Thanks for the review,

-- Steve