linux-kernel - Re: Ftrace: Static function graph not work

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] [day] [month] [year] [list]

Date:   Tue, 4 Apr 2017 17:31:41 +0800
From:   Zong Li <zongbox@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Ftrace: Static function graph not work

2017-03-31 21:42 GMT+08:00 Steven Rostedt <rostedt@...dmis.org>:
> On Thu, Mar 23, 2017 at 11:28:03AM +0800, Zong Li wrote:
>> Hi all,
>>
>> I test the static function graph for ARM, x86 and x86_64 architecture
>> on linux-3.10 and linux-4.9, and I find it works correctly only for
>> x86_64 on linux-4.9.
>
> I'm curious. Are you just testing these to run normal QA, or do you actually
> have a need for static function graph tracing? Reason why I ask, is that we
> are thinking about removing it completely, because dynamic function tracing is
> the only one that really makes sense. I only keep it around on x86 because
> static function tracing is easy to implement on other archs, and I like to
> still test it on x86. But that reason is getting weaker.

It's exactly. I think the dynamic function tracing is really makes sense.
I find this problem because I'm porting the static and dynamic
function tracer for
the AndesCore architecture and we are planing to contribute our
architecture in the future.
I had implemented it on kernel-3.4 before, and it work fine,
so this is reason why I sent this mail for my confusion.

>> After the following commit, the function tracer also be registered
>> when registering the function graph tracer.
>>
>> commit 2940c25bec92f40a3f7f32504b8ea115d1701892
>> Author:     Steven Rostedt (Red Hat) <rostedt@...dmis.org>
>> CommitDate: Wed Dec 4 10:57:05 2013 -0800
>>
>>     ftrace: Fix function graph with loading of modules
>>
>>
>> The arch-depend code implement the mcount function pseudo code like:
>>
>> void mcount(void)
>> {
>>         ...
>>         if (ftrace_trace_function != ftrace_stub)
>>                 goto do_trace;
>>
>> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>        if (ftrace_graph_return != ftrace_stub ||
>>            ftrace_graph_entry != ftrace_graph_entry_stub)
>>                ftrace_graph_caller();
>> #endif
>>         return;
>>
>> do_trace:
>>         ...
>> }
>>
>> The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
>> because function tracer is registered too, so the function graph part
>> will not be executed.
>>
>>
>> On the other hand, I find the another patch to resolve this situation,
>> and it is reason that x86_64 architecture can work correctly.
>>
>> commit 62a207d748dd9224140a634786b274fdb6ece0b9
>> Author:     Steven Rostedt (Red Hat) <rostedt@...dmis.org>
>> CommitDate: Mon Nov 24 15:02:25 2014 -0500
>>
>>     ftrace/x86: Have static function tracing always test for function graph
>>
>>
>> so, is this problem tending to handle by each architecture? or maybe
>> it is need to solve by generic code?
>
> Well, it's written in assembly, so having it be generic code is out of the
> question. But I should fix this for x86_32 if that's broken there. Other archs
> are on their own.

Yes, I think it should be handle on architectures own and I'll fix it
on our arch.

>>
>>
>> This is my first mail to mailing list, please excuse having mistake
>> and let me know.
>
> I noticed this email because you sent a "ping" with me Cc'd. Just to let you
> know, this mailing list gets over 600 emails a *day*! Nobody reads all of it.
> For future reference, always Cc those that you want to read your email when
> sending to the list, otherwise it will get lost in the flood.
>
> -- Steve

I deeply appreciate your reply and notice. Thanks a lot!