linux-kernel - Re: [PATCH v2] ftrace: Hide a extra entry in stack trace

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: <b0ec6a2d-8734-46f3-8cfb-f2bbe17dbf59@gmail.com>
Date: Wed, 2 Oct 2024 15:43:35 +0900
From: Tatsuya S <tatsuya.s2862@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ftrace: Hide a extra entry in stack trace



On 10/1/24 10:47 PM, Steven Rostedt wrote:
> On Tue, 1 Oct 2024 22:27:03 +0900
> ts <tatsuya.s2862@...il.com> 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.


thanks.