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

[Jim Keniston]

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

-
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/