linux-kernel - Re: [PATCH 4/4] tracing/function-return-tracer: Support for dynamic ftrace on function return tracer

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]

Date:	Wed, 26 Nov 2008 20:16:15 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Tim Bird" <tim.bird@...sony.com>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] tracing/function-return-tracer: Support for dynamic ftrace on function return tracer

Hi Tim,

2008/11/26 Tim Bird <tim.bird@...sony.com>:
> � wrote:
> Very sorry I'm coming to this thread late.  I didn't notice it until
> today.
>
> Not to question the whole approach, and sorry if this was
> discussed before, but why wasn't -finstrument-functions used
> to instrument the function exits.  This worked well for KFT
> (See http://elinux.org/Kernel_Function_Trace).  I'm not sure if the
> function prologue and epilogue modifications done by -mcount are
> different than -finstrument-functions, but I thought I remember something
> about Steven testing -finstrument-functions in an early version of ftrace.

Yes, we discussed it earlier but because of some reasons (kernel size,
dynamic patching
cost), we used a stack of return address for each task.
See the discussion about using -finstrument-functions:
http://lkml.org/lkml/2008/10/30/372

> By the way, I'm really excited to see this "function_cost" stuff being
> worked on.  It has proven to be extremely useful for analyzing early boot
> latencies at Sony.
>
> Sorry again I didn't catch this and previous related threads
> earlier.  I have some post-processing tools which might be useful here.

That would be welcome. Note that the output of this tracer is a bit different
from KFT. I'm currently working on the a C-like output:
http://lkml.org/lkml/2008/11/25/389
So perhaps the post-processing would have to be done in a way quite
different from this
used on KFT traces. I don't know.

> Also, I've found it very handy to have the capability to filter by minimum
> function duration.  Is there any work to do that with the
> current system.  If not, maybe I could take a look at that and see if
> I can add something.

Yes there would be some modifications to do so.
I guess the best thing to do that would be to use the trace_options
files in which
any tracer can set some custom flags. See set_flag callback in struct tracer.

For now, this file can only receive boolean value on particular options.
For example if you have a tracepid option. You either echo tracepid or
notracepid to
set the value on trace_option. Your needs would require this file, and
this set_flag callback,
to receive string values, like kernel parameters, by using get_option().
This way you could set duration=50 as an example.
This work is more tracing specific than function-return-tracer
specific (it was renamed function_branch
tracer recently).

After that, handling this minimal duration set on function branch
tracer will be pretty easy. :-)

One other solution would be to have a dedicated debugfs file for this
tracer but that would be a pity, IMHO,
to not let too other tracers having custom options with string values.

If you want to have a look on the current state, see the -tip tree.

I will add you in Cc for next patches....