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]

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

2008/11/24 Ingo Molnar <mingo@...e.hu>:
> 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.

Great!

> 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.


Yes, too much complex, too much error prone.... And such a thing
would have been better done from user space...

> 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.


Yes, I'm currently burning a 64 bits distro :-)
Very few things should be added or modified to work on 64. The most adds
will be in entry64.S and perhaps very few things in ftrace.c ...
That should come soon.

Note that I plan to adapt it for other archs too such as ARM and Sparc64, but
perhaps more likely for 2.6.30,  I will see.....

Thanks :-)
--
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/