Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes(un)registration and exception handling.

[Mathieu Desnoyers]

* Srikar Dronamraju (srikar@xxxxxxxxxxxxxxxxxx) wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> [2010-09-03 19:19:09]:
> 
> > > 
> > > However I would have an issue with making inode based probing the
> > > default.
> > > 1. Making all probing based on inode can be a performance hog.
> > 
> > How so? You can add filters if you want.
> 
> The breakpoint exception and singlestep account for a substaintial time
> of the uprobes probe handling. With increasing number of breakpoint hits and
> singlesteps, wouldnt the overall load increase?
> 
> > 
> > > 2. Since unlike kernel space, every process has a different space, so
> > > why would we have to insert breakpoints in each of its process space if
> > > we are not interested in them.
> > 
> > You don't have to, but you can. The problem I have with this stuff is
> > that it makes the pid thing a primary interface, whereas it should be
> > one of many filter possibilities.
> 
> I think the otherway, 
> Why instrument a process and filter it out, if we are not interested in it.
> While instrumenting kernel, we dont have this flexibility. So
> having a pid based filter is the right thing to do for kernel
> based tracing.
> 
> If we can get the per process based tracing right, we can build
> higher lever stuff including the file based tracing easily.
> 
> All tools/debuggers in the past have all worked with process based
> tracing.
> 
> Tools like gdb can actually use the displaced singlestepping
> feature that uprobes provides. Some gdb developers have told on LKML
> earlier that they would be willing to use displaced singlestepping if
> the kernel provides an API that they can use.
> 
> Also about the security perspective when allowing normal users use
> perf to trace their applications. Using this model, we dont have to
> write extra filters to limit them. These filters might allow uprobe
> handlers on only tasks belonging to that user. However it still
> interrupts task of other users. And as I said earlier, breakpoint
> exception and singlestepping actually make a very very substantial part
> of the handling. The actual uprobe handler depending on what it does
> might actually be very minimal part of the uprobe probe handling.

I think we are both partially right in slightly different ways. I think Peter is
right in that the PID should not be mandatory (e.g. specifying a PID of 0 should
apply to all tasks), and you are also right in that being able to apply the
"filter" directly at the executable image level is vital for performance.

So how about this: we can provide both task and inode selection arguments. The
task selection argument can be 0 (apply to all tasks) or non-zero (one task
specifically). The inode argument would be mandatory.

Then, eventually, we can enhance the generic filtering facility so it can be
made aware of filtering shortcuts provided by the instrumentation (in this case,
uprobes would provide a per-tgid filtering shortcut).

Thoughts ?

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/