Messages in this thread | | | Date | Thu, 25 Mar 2010 14:11:52 +0530 | From | Srikar Dronamraju <> | Subject | Re: [PATCH v1 7/10] Uprobes Implementation |
| |
> > 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
| |