This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2.6.12-rc1-mm3] [1/2] kprobes += function-return


On Mon, 2005-04-04 at 01:15, Prasanna S Panchamukhi wrote:
> Hi Hien,
> 
> This patch looks good to me, but I have some comments on this patch.
> 
> >int register_kretprobe(struct kprobe *kp, struct rprobe *rp);
...
> >int register_jretprobe(struct jprobe *jp, struct rprobe *rp);
...
> 
> Why two interfaces for the same feature?
> You can provide a simple interface like
...
> int register_returnprobe(struct rprobe *rp) {
...

> independent of kprobe and jprobe.
> This routine should take care to register entry handler internally if not 
> present. This routine can check if there are already entry point kprobe/jprobe
> and use some flags internally to say if the entry jprobe/kprobe already exists.
> 
...
> 
> make unregister exitprobes independent of kprobe/jprobe.
> 
...
> 
> Please let me know if you need more information.
> 
> Thanks
> Prasanna

We thought about that.  It is a nicer interface.  But I'm concerned that
if the user has to do
	register_kprobe(&foo_entry_probe);
	register_retprobe(&foo_return_probe);
then he/she has to be prepared to handle calls to foo that happen
between register_kprobe and register_retprobe -- i.e., calls where the
entry probe fires but the return probe doesn't.  Similarly on
unregistration.

Here are a couple of things we could do to support registration and
unregistration of retprobes that can be either dependent on or
independent of the corresponding j/kprobes, as the user wants:

1. When you call register_j/kprobe(), if kprobe->rp is non-null, it is
assumed to point to a retprobe that will be registered and unregistered
along with the kprobe.  (But this may make trouble for existing kprobes
applications that didn't need to initialize the (nonexistent) rp
pointer.  Probably not a huge deal.)

OR

2. Create the ability to (a) register kprobes, jprobes, and/or retprobes
in a disabled state; and (b) enable a group of probes in an atomic
operation.  Then you could register the entry and return probes
independently, but enable them together.  We may need to do something
like that for SystemTap anyway.

Jim Keniston
IBM Linux Technology Center


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]