This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers
- From: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- To: "Martin J. Bligh" <mbligh at google dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, "Frank Ch. Eigler" <fche at redhat dot com>, Paul Mundt <lethal at linux-sh dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- Date: Tue, 19 Sep 2006 13:41:12 -0400
- Subject: Re: [PATCH] Linux Kernel Markers
- References: <20060918234502.GA197@Krystal> <20060919081124.GA30394@elte.hu> <451008AC.6030006@google.com>
Hi Martin,
* Martin J. Bligh (mbligh@google.com) wrote:
> Why don't we just copy the whole damned function somewhere else, and
> make an instrumented copy (as a kernel module)? Then reroute all the
> function calls through it, instead of the original version. OK, it's
> not completely trivial to do, but simpler than kprobes (probably
> doing the switchover atomically is the hard part, but not impossible).
> There's NO overhead when not using, and much lower than probes when
> you are.
>
I just thought about your idea and I think it can be very powerful. I think it
can be a lot easier with a probe at the beginning of the function than changing
function pointers everywhere. First of all, if we just think about accessing
easily internal variables, we could think of this simple trampoline scheme :
1 - load the instrumented function with modprobe
2 - use kprobe to reroute the first instructions of the original function to the
new one.
3 - _not_ use the special kprobe_ret, simply return at the end of the
instrumented function.
Then, if we want to optimize the speed of this mechanism, we can deploy
djprobes : it would greatly help them to know in advance where the probe is
located. We would have to see if the prologue of a function is a good spot to
put a jump (it does not seem to be the case however) :( .
To stop this tracing behavior, we would just have to remove the kprobe.
Unloading of the instrumented module can be difficult though (we have to be sure
the code will no longer be executed).
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68