Re: [PATCH v2] ftrace: Hide a extra entry in stack trace
From: Google
Date: Wed Oct 02 2024 - 10:08:30 EST
On Wed, 2 Oct 2024 15:43:35 +0900
Tatsuya S <tatsuya.s2862@xxxxxxxxx> wrote:
>
>
> On 10/1/24 10:47 PM, Steven Rostedt wrote:
> > On Tue, 1 Oct 2024 22:27:03 +0900
> > ts <tatsuya.s2862@xxxxxxxxx> wrote:
> >
> >>> ...
> >>> sh-140 [001] ...1. 18.352601: myevent: (vfs_write+0x4/0x560)
> >>> sh-140 [001] ...1. 18.352602: <stack trace>
> >>> => ksys_write
> >>> => do_syscall_64
> >>> => entry_SYSCALL_64_after_hwframe
> >>> sh-140 [001] ...1. 18.352602: vfs_write <-ksys_write
> >>> sh-140 [001] ...1. 18.352604: <stack trace>
> >>> => ftrace_regs_call
> >>> => vfs_write
> >>> => ksys_write
> >>> => do_syscall_64
> >>> => entry_SYSCALL_64_after_hwframe
> >>> ------
> >>> As you can see, myevent skips "vfs_write".
> >>> (and function tracer still have ftrace_regs_call() )
> >>
> >> Thanks for the other tests. This issue may be function_trace_call()
> >> specific problem.
> >>
> >> So I will change the place to increment skip number.
> >
> > My fear is that we are going to just break it elsewhere. The problem with
> > the "skip" is that there's so many configurations when we get here, we may
> > not really know what to skip. If the compiler inlines something, then we
> > may skip something we do not want to.
> >
> > I rather have extra information than not enough.
> >
> > -- Steve
>
> It may not be clean and be bit redundant, but I think it would be more
> maintainable to treat
>
> "skip(and skipped functions)" separately only at the top(parent) of
> functions that display stack trace.
I think you'd better make a set of test programs which gets the stacktrace
with several different conditions (combinations of tracers/probes/kconfgis)
at first. Then we can make sure it does not break anything.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>