[RFC] [PATCH] Multiple kprobes at an address redux (take4)

[Ananth N Mavinakayanahalli]

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