lkml.org 
[lkml]   [2002]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Kernel probes for i386 2.5.26
Date
On Sat, 20 Jul 2002 10:17:44 +0530, Rusty Russell wrote:

> Hi Linus,
>
> This is a neat patch by Vamsi which allows code to trap on
> kernel instructions. The IBM guys have stuff for non-intrusive testing,
> debugging, instrumentation on top of this. It's also nice to insert
> assertions in core code without having to reboot 8)
>
> Thanks,
> Rusty.
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>
> Name: Kernel Probes Patch
> Author: Vamsi Krishna S
> Status: Tested on 2.5.26 SMP
>
> D: This patch allows trapping at almost any kernel address, useful for
> D: various kernel-hacking tasks, and building on for more D:
> infrastructure. This patch is x86 only.
>

Here is a somewhat brief writeup we had available about
kernel probes - hope it helps provide a little more
information as suggested by some people offline.

Feedback, questions, comments welcome !

Regards
Suparna

Suparna Bhattacharya
Linux Technology Center
IBM Software Lab, India
E-mail : suparna@in.ibm.com


Kernel Dynamic Probes
---------------------

Kernel Dynamic Probes (kprobes) provides a lightweight interface
for kernel modules to implant probes and register corresponding
probe handlers. A probe is an automated breakpoint that is
implanted dynamically in executing (kernel-space) modules without
the need to modify their underlying source. Probes are intended
to be used as an ad hoc service aid where minimal disruption
to the system is required. They are particularly advocated in
production environments where the use of interactive debuggers
is undesirable. kprobes also has substantial applicability in
test and development environments. During test, faults may be
injected or simulated by the probing module. In development,
debugging code (for example a printk) may be easily inserted
without having to recompile to module under test.

With each probe, a corresponding probe event handler address
is specified. Probe event handlers run as extensions to the
system breakpoint interrupt handler and are expected to have
little or no dependence on system facilities. Because of this
design point, probes are able to be implanted in the most
hostile environments -- interrupt-time, task-time, disabled,
inter-context switch and SMP-enabled code paths -- without
adversely skewing system performance.

kprobes Interfaces
--------------------
kprobes provides two interfaces: register_probe and
unregister_probe.

register_probe:
----------------

Registration defines the probe location, which must be at an
instruction boundary that precedes any associated opcode
prefixes. It also defines three call-back addresses for the
probing module:

- the probe-event handler address, which is called as the
probed instruction is about to execute. On return kprobes
will single-step the probed instruction;
- the post-execution handler address, which is called when
single-stepping completes
- the fault handler address, which is called if an exception
is generated for any instruction within the fault-handler
or when kprobes single-steps the probed instruction.

register_probe passes a struct kprobe:

struct kprobe {
u8 * addr; /* location of the probe point */
spinlock_t lock;
struct list_head list;
unsigned long status;
/* Called before addr is executed. */
kprobe_pre_handler_t pre_handler;
/* Called after addr is executed, unless... */
kprobe_post_handler_t post_handler;
/* ... called if executing addr causes a fault (eg. page fault).
* Return 1 if it handled fault, otherwise kernel will see it. */
kprobe_fault_handler_t fault_handler;
u8 opcode;
};

addr:
the location of the probepoint, which must be at an instruction
boundary including any associated opcode prefixes - referencing
label in C will guarantee this.

pre_handler:
the function that will be called when the probed instruction
is about to execute.

post_handler:
the function that will be called on completion of successful
execution of the probed instruction

fault_handler:
the function that will be called if any software
exceptions occur
- while executing inside the probe_handler
- when single-stepping the probed instruction

The user is required to retain this structure in resident memory
for as long as the probe remains active. Some of the fields are
used internally by kprobes and must be initialised to NULL
or ZERO. The fields the user is required to initialise are the addr
and the pre_handler fields. The post_handler and fault_handler
are optional.


unregister_probe:
-----------------

unregister_probe also requires struct kprobe. The user has
to unregister explicitely all registered probes
before removing the probe handling module.

Extensions to Kernel Dynamic Probes
-----------------------------------

Kernel Dynamic Probes has been developed from the full
Dynamic Probes patch. It includes the essential mechanism to
allow probes to exist in kernel space. The RPN Language
Interpreter, Watchpoints and User-space probes extensions,
which are part of the Dynamic Probes Package, will be available
as add-on patches from the Dynamic Probes web-site.

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

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.174 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site