[Ksummit-2008-discuss] DTrace

Ananth N Mavinakayanahalli ananth at in.ibm.com
Sun Jun 29 22:10:34 PDT 2008

On Sun, Jun 29, 2008 at 10:40:02AM +0200, Christoph Hellwig wrote:
> On Sat, Jun 28, 2008 at 12:56:05PM +0530, Ananth N Mavinakayanahalli wrote:
> > > ptrace, it won't help you anything at all right now.  uprobes is very
> > > basic infrastructure that in theory allows doing some kprobes-like
> > > probes on userspace processes.  It would be a building block to
> > > implement something like this, but in the current form is far from
> > > what's needed.
> > 
> > Right, it is a start though. We are awaiting utrace's acceptance upstream
> > after which we'll post the uprobes patches too.
> Actually the uprobes code that has been floating around for a while is
> the completely wrong approach.

Hope you are referring to the uprobes code based on utrace.

> The need to generated a kernel module
> that needs deeply internal VM and task management details just to
> perform tracing of userspace application code is wrong.  This whole
> approach needs to go back to the drawing board.  I still haven't found a
> good explanation of why the actual tracing code even has to execute in
> kernelspace with all the associated risk of bugs and security problems
> while it would be much easier to run the actual tracing data aquisition
> in userspace where it belongs.

Uprobes, in the current approach, hooks on to the per-task utrace event
handlers. Utrace event handlers, by design run in the kernel (unless we
want to go back to the ptrace model of context switches and intercepting
signals). The current design enables running handlers in the context of
the traced process. Also, the handler as such can do just minimal stuff
in the kernel (dump data from the process address space - mostly
restricted to what access_process_vm() gives you), and post processing is
left to userspace.

If you have ideas for better ways of doing this, we are all ears.


More information about the Ksummit-2008-discuss mailing list