linux-kernel - Re: Human readable output for 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]

Message-ID: <20081124162719.GA11532@elte.hu>
Date:	Mon, 24 Nov 2008 17:27:19 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Human readable output for function return tracer

* Frédéric Weisbecker <fweisbec@...il.com> wrote:

> Hi,
> 
> I'm planning to apply an idea proposed by Ingo to make the output on
> the function return tracer
> more "eyes-parsable".
> The idea consists on a trace which has flow similar to C code:
> 
> func1() {
>     func2() {
>         func3() {
>         }
>     }
>     func4() {
>     }
> }
> 
> (With time of execution added on closing braces).
> 
> The problem is that the traces arrive in the reverse order, according
> to the fact that functions
> are traced on return.
> The order corresponding to the above example would be as the following:
> 
> func3, func2, func4, func1
> 
> Oh and we have the parent in a return trace, so we would actually have:
> 
> func2->func3

[ Note: here we'd also have: ]

  func1->func2

> func1->func4
> ....    ->func1

it's basicaly a representation of the callgraph in polish notation.

> This trace flow doesn't make the things easy to produce our C like 
> code.
> 
> So I found only one solution which have both pros and cons. I could 
> send a "pre-trace" to the ring-buffer to signal that function x with 
> depth y is beeing called (when we enter the function).

that's OK i think. It will double the number of events, but will 
simplify everything immensely - especially if we have small 
imperfections in the callgraph arising out of IRQ entries.

Note that we _could_ render it all from the return events alone, 
because we have the full callgraph available. But it would be either 
very memory-intense or very CPU-intense: we'd either have to buffer up 
all the return events in a reverse-stack sort of construct (which 
could grow much larger than the return stack itself), or we'd have to 
reconstruct it on the fly by constantly scanning forwards to discover 
the context of the printout. Both can have pretty ugly worst-case 
behavior with certain call graph layouts.

So i think you made a good call - lets keep it simple for now.

Also, do you have any thoughts about how to extend the return-tracer 
to 64-bit x86? It should work pretty well i think - the return value 
has to be extended to 64 bits but that's pretty much all.

	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/