Re: [RFC] [PATCH 4/7] Uprobes Implementation

[Ananth N Mavinakayanahalli]

On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
 On Mon, Jan 11, 2010 at 05:55:53PM +0530, Srikar Dronamraju wrote:
  +static const struct utrace_engine_ops uprobe_utrace_ops = {
  +   .report_quiesce = uprobe_report_quiesce,
  +   .report_signal = uprobe_report_signal,
  +   .report_exit = uprobe_report_exit,
  +   .report_clone = uprobe_report_clone,
  +   .report_exec = uprobe_report_exec
  +};
 
 
 So, as stated before, uprobe seems to handle too much standalone
 policies such as freeing on exec, always inherit on clone and never
 on fork. Such rules should be decided from uprobe clients not
 from uprobe itself and that makes it not enough flexible to
 be usable for now.

The freeing on exec is only housekeeping of uprobe data structures. And
probepoints are inherited only on CLONE_THREAD and not otherwise, simply
since the existing probes can be hit in the new thread's context. Not
sure what other policy you are hinting at.

 For example if we want it to be usable by perf, we have two ways:
 
 - a trace event. Unfortunately, like I explained in a previous
   mail, this doesn't seem to be a suitable interface for this
   particular case.
 
 - a performance monitoring unit, with the existing unified interface
   struct pmu, usable by perf.
 
 
 Typically, to use it with perf toward a pmu, perf tools need to
 create a uprobe on perf process and activate its hook on the next exec.
 Thereafter, it's up to perf to decide if we inherit through clone
 and fork.

As mentioned above, the inheritance is only for threads. It should be
fairly easy to inherit probes on fork, and that can be made a perf based
policy decision.

 Here I fear utrace and perf are going to collide.

Utrace does not mandate any of the above concerns you've mentioned.
Utrace just provides callbacks at the said events and uprobes can be
tweaked to accommodate perf's requirements as possible, as feasible.

 See how could be the final struct pmu (we need to extend it
 to support utrace):
 
 struct pmu {
   enable() - called we schedule in a context where we want
 a uprobe to be active. Called very often
 disable() - the above opposite
 
 /* Not yet existing callbacks */
 
 hook_task() - called when a process is created which
we want to activate our hook
would be typically called once on
exec if we have set enable_on_exec
and also on clone()/fork()
if we want to inherit.
 }
 
 
 The above hook_task (could be divided in more precise callback events
 like hook_on_exec, hook_on_clone, etc...) would be needed by perf
 to drive correctly utrace and this is going to collide with utrace
 callbacks that notify execs and forks.
 
 Probably utrace can be kept for all the utrace breakpoint signal
 handling an so. But I guess the rest can be implemented on top
 of a struct pmu and driven by perf like we did with hardware
 breakpoints re-implementation.
 
 Just an idea.

Well, I wonder if perf can ride on utrace's callbacks for the
hook_task() for the clone/fork cases?

Ananth

Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

[Frank Ch. Eigler]

Frederic Weisbecker fweis...@gmail.com writes:

 [...]
 This is much more tricky in the case of uprobes as I see two
 ways to work with it:
 - probing on an already running process
 - probing on a process we are about to run
 [...]

As you might expect, in systemtap we've had to figure out this area
some time ago.  We use another utrace consumer called task finder
that registers interest in present / future processes, and gives us
kernel-space callbacks when these come and go.  You could merge it or
something like it.

- FChE

Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes

[Frank Ch. Eigler]

Hi -

  As you might expect, in systemtap we've had to figure out this area
  some time ago.  We use another utrace consumer called task finder [...]
 
 So, could you tell us how the task-finder works and is implemented?

The code may be found at runtime/task_finder* in the systemtap sources.
There is a simple interest-registration structure/API that identifies
processes / shared libraries of interest, and a set of callbacks to be
invoked when said processes/shared libraries are mapped or unmapped.

It is implemented in terms of utrace callbacks for process/thread
lifetime monitoring, and utrace syscall callbacks for tracking shared
library segments being mapped and unmapped.

http://sourceware.org/git/?p=systemtap.git;a=tree;f=runtime


 I think we'd better clarify what functions are required for uprobes
 and pmu, and I think we may be able to re-implement improved pmu on
 utrace.

I don't see any collision between pmu / perf / utrace, so nothing is
really required for them or simple usage of uprobes.  If you wish to
track dynamic process/shared-library lifetimes, then you need extra
code somewhere to respond to those changes.  Layering this dynamic
capability seems like the natural way to go, and is easily done with
utrace and/or tracepoints.

- FChE

Re: [RFC] [PATCH 4/7] Uprobes Implementation

[Jim Keniston]

On Tue, 2010-01-12 at 13:44 +0530, Ananth N Mavinakayanahalli wrote:
 On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
...
  So, as stated before, uprobe seems to handle too much standalone
  policies such as freeing on exec, always inherit on clone and never
  on fork. Such rules should be decided from uprobe clients not
  from uprobe itself and that makes it not enough flexible to
  be usable for now.
 
 The freeing on exec is only housekeeping of uprobe data structures. And
 probepoints are inherited only on CLONE_THREAD and not otherwise, simply
 since the existing probes can be hit in the new thread's context. Not
 sure what other policy you are hinting at.
 
...
  
  
  Typically, to use it with perf toward a pmu, perf tools need to
  create a uprobe on perf process and activate its hook on the next exec.
  Thereafter, it's up to perf to decide if we inherit through clone
  and fork.
 
 As mentioned above, the inheritance is only for threads. It should be
 fairly easy to inherit probes on fork, and that can be made a perf based
 policy decision.
 

One reason we don't currently support inheritance (or cloning) of
uprobes across fork is that a uprobe object is (a) per-process (and I
think we want to keep it that way); and (b) owned by the uprobes client.
That is, the client creates and populates that uprobe object, and passes
a pointer to it to both register_uprobe() and unregister_uprobe().  We
could clone this object on fork, but then how would the client refer to
the cloned uprobes in the new process -- e.g., to unregister them?

I guess each cloned uprobe could remember its patriarch uprobe -- its
ultimate ancestor, the one created by the client; and we could add an
unregister_uprobe_clone function that takes both the address of the
patriarch uprobe and the pid of the (clone) uprobe to be unregistered.

It has also been suggested that it might be more user-friendly to 
let the client discard (or reuse) the uprobe object as soon as
register_uprobe() returns.  register_uprobe() would presumably copy 
everything it needs from the uprobe to the uprobe_kimg, and pass back 
a handle (e.g., the address of the uprobe_kimg) that the client can
later pass to unregister_uprobe() -- or unregister_uprobe_clone().  (In
this case, only the uprobe_kimg would be cloned.)  It might be good to
consider both these enhancement requests together.

Anyway, as previously described, the clone-on-fork feature can be (and
has been) implemented by a utrace-based task-finder that notices forks,
and creates and registers a whole new set of uprobes for the new
process.

Jim