linux-kernel - Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace

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: <20081113091454.GH25479@elte.hu>
Date:	Thu, 13 Nov 2008 10:14:54 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] tracing/function-return-tracer: Call
	prepare_ftrace_return by registers

* Ingo Molnar <mingo@...e.hu> wrote:

> Or perhaps we could name it the "callgraph" tracer? (as opposed to 
> the simpler function tracer which traces function entries) Note that 
> we could use the output to build function call coverage graphs.
> 
> It definitely must convey the idea that this is a more capable (and 
> also more expensive) form of function tracing.

on a related note.

Frederic, it would be nice to fine-tune the tracer output to convey 
the callgraph information more clearly. Here's a mockup of a good 
default output:

  getnstimeofday() {
   set_normalized_timespec() {
    clocksource_read() {
     acpi_pm_read()                     ( 1547 ns)
    } clocksource_read()                ( 1951 ns)
   } set_normalized_timespec()          ( 2200 ns)
  } getnstimeofday()                    ( 2354 ns)

  [...]

Such output would be _very_ nice and intuitive to have. Developers 
would love it instantly. Note its C-ish syntax - that is obviously the 
easiest to parse for kernel developers.

and note how natural it will be in the future to embellish certain 
function calls in the above trace, for example with function 
arguments:

    clocksource_read("acpi_pm") {

i'd suggest to hide the offset bit of the ksym (like the mockup does 
it - unless a tracing_option is set for more verbose symbol output). 
For these traces it's almost always useless and the context tells us 
in 99% of the cases where a function got called.

Easiest would be to add a depth field to the trace entry as well, to 
make sure we get the right depth in the end, even if we somehow mix up 
the trace entries.

We could also trace function entry and exit separately, and 
post-process the call stack (and the cost) during trace output 
formatting - not during tracing.

Hm?

	Ingo
--
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/