This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: [RFC] [PATCH] Multiple kprobes at an address redux (take4)
- From: Ananth N Mavinakayanahalli <amavin at redhat dot com>
- To: prasanna at in dot ibm dot com
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 18 Apr 2005 08:17:08 -0400
- Subject: Re: [RFC] [PATCH] Multiple kprobes at an address redux (take4)
- References: <20050418045757.GA11574@in.ibm.com>
Prasanna S Panchamukhi wrote:
Ananth,
+static int register_aggr_kprobe(struct kprobe *p)
+{
+ int ret = 0;
+ unsigned long flags = 0;
+ struct kprobe *old_p, *ap;
+
+ ap = kcalloc(1, sizeof(struct kprobe), GFP_KERNEL);
+ if (!ap)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&kprobe_lock, flags);
+ old_p = get_kprobe(p->addr);
+ if (old_p) {
+ if (old_p->break_handler || p->break_handler) {
+ ret = -EEXIST;
+ goto free_ap;
In your design document and in the code above shows that
multiprobe feature is incompatable with jprobes.
If a user wants of insert a kprobe at the entry point and exit probe at a
function exit, your patch addressing multiple handler feature is useful.
but usually users are interested in both jprobe at the entrypoint (to dump
arguments) and to dump return values using exit probe feature.
To do this user succeeds inserting a jprobe at the entrypoint,
but when the user tries to register the exit probe for the same function,
it fails.
exit probe feature needs to register a kprobe at the entrypoint and if
there is a jprobe at the entrypoint, it is bound to fail.
Yes, this is a "feature" of the design as of now - kprobes and jprobes
can't co-exist. I have a few ideas I am working on to fix the issue, but
it does seem to be a bit tricky.
FWIW, all takes on this feature have had the restriction. I hope to have
a solution to this soon. Ideas are welcome :)
Also you need to add comments explaining about the new routines added
in your patch.
Will do!
Thanks,
Ananth