Re: [PATCH v1 7/10] Uprobes Implementation

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

> 
> I'm not sure, currently all the tracing bits require root. One of the
> complications is that dynamic trace events (kprobes and uprobes) share a
> global namespace, so making that accessible to users might be
> interesting.
> 
> So one thing we can do to avoid some of the trap overhead is to
> de-couple the trace event creation from trace event enable (pretty much
> already so for existing implementations), so while you define a dynamic
> trace event as dso:sym, you provide ways to enable it globally and per
> task.
> 
> We'd basically need a global and per-task refcount on enable and make
> sure the breakpoint is installed properly for (global || task).

Yes, when we allow two or more probes to co-exist at a probepoint, we
will be able to do this.

> 
> That way a perf per-cpu event will do the global enable, and a perf
> per-task event will do the task enable.
> 

> 
> A double scribble will be an issue for the current generation of
> debuggers anyway, right?
> 

double scribble as in two apps writing to the same address? Uprobes
handles this by failing into insert probes at location where there is a
breakpoint already inserted. So if both apps were to use the uprobes
interface, then they could co-operate and co-exist. (This would need the
feature in uprobes to have multiple probes per probepoint which is
excluded in this RFC).

> But yes, I suppose if you want to use uprobes for debuggers then yes it
> makes sense to allow to put the task to sleep. One way would be to
> provide means for the handler to detect the context and simply always
> return -EFAULT from the trap context.
> 

Yes, thats certainly possible. However lets consider the case when we
allow multiple probes per probepoint and one handler faults (handler
detects it could be sleeping) while the other handler may or may not
fault (handler could be doing a copy_from_user). 
When the thread switches to task context and runs the first handler but
it has no state information about the second handler having run in the
interrupt context. So here we may be unable to decide if we should run
the second handler or not.

--
Thanks and Regards
Srikar