linux-kernel - Re: [PATCH 0/2] ftrace: updates to tip

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: <alpine.DEB.1.10.0901162003000.9232@gandalf.stny.rr.com>
Date:	Fri, 16 Jan 2009 20:14:25 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Chris Mason <chris.mason@...cle.com>
Subject: Re: [PATCH 0/2] ftrace: updates to tip

On Fri, 16 Jan 2009, Ingo Molnar wrote:

> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > > I was afraid you would say that :-)
> > > 
> > > Yes, we could add something to do this. It would take some thought on 
> > > a good api, and implementation. This is not an easy task by any means. 
> > > We need a way to map between a function call and a tracer, where a 
> > > function call can call more than one tracer.
> > 
> > Note that some other things could be consolidated under per function 
> > metadata: for example set_graph_function - which really is a per 
> > function attribute too. Plus a lot of new things would be enabled i 
> > think.
> 
> a few other things that could be per-function attributes:
> 
>  - Using function trace 'limits': trace a function 50 times and dont trace 
>    it afterwards. Each invocation of that function decreases the
>    remaining-count by one. For example:
> 
>      echo 'btrfs_join_transaction:#2' >> set_ftrace_filter
> 
>    Would specify that we generate two trace entries of
>    btrfs_join_transaction(), then stop tracing this function.
> 
>  - Using function-triggered tracing: a function could be specified (via a 
>    filter format extension) to act as a 'start tracing' trigger. Another 
>    extension would be 'stop tracing' trigger.
> 
>    For example:
> 
>       echo 'btrfs_join_transaction:+' >> set_ftrace_filter
>       echo 'btrfs_commit_transaction:-' >> set_ftrace_filter
> 
>    The '+' is a start-tracing trigger condition, the '-' is a stop-tracing 
>    trigger condition. All function calls between btrfs_join_transaction() 
>    and btrfs_commit_transaction() would be traced.
> 
> The two could be combined - to generate the trace of a single btrfs 
> transaction, one could do:
> 
>       echo 0 > tracing_enabled
>       echo 'btrfs_join_transaction:+#1' >> set_ftrace_filter
>       echo 'btrfs_commit_transaction:-#1' >> set_ftrace_filter
>       echo 1 > tracing_enabled
> 
> Other extensions are possible too:
> 
>  - Trace length triggers. For example one could do:
> 
>       echo 'btrfs_join_transaction:+*#10' >> set_ftrace_filter
> 
>    To trace 10 function calls [allowed by current filter settings] after
>    the first btrfs_join_transaction() call - and stop tracing after those 
>    10 trace entries.
> 
> This would allow the creation of "surgical" one-time traces - of events 
> and functions one is specifically interested in.

This all sounds great, but it would add a lot of conditionals into a 
extremely hot function tracer path. Remember, we are not modifying the 
calls to mcount to call a registered function directly. All functions 
being traced must call the same function. The reason is that mcount is not 
a normal function in C. It does not behave the same as other functions, 
and must be implemented in assembly (as you already know ;-) The dynamic 
tracer calls into a trampoline that calls the registered function. There 
is only one trampoline, so only one function gets called on a trace. We 
can at most enable or disable a given function. We can not change what 
that function calls (without implementing it for every arch).

This means any conditional that you make, must be made for all traced 
functions. And this will put an overhead onto the system.

Now we can register multiple functions to be called by a traced function, 
or pick and choose what function will be called by a traced function
depending on what option was asked for. But all traced functions will 
still call the same code. We can start experimenting, but I would 
be more keen on how this will be used by developers. Chris gave a great 
example of how he would use his feature. Doing what you ask would require 
a rewrite of most the code. I hate to do that and have only 2 or 3 people 
using it :-/

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/