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  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 <>
To:     Steven Rostedt <>
Subject: Re: Ftrace: Static function graph not work

2017-03-31 21:42 GMT+08:00 Steven Rostedt <>:
> 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) <>
>> 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;
>>        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) <>
>> 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!

Powered by blists - more mailing lists