Message-ID: <863e9df20711140530h69df9107g38e293aab278686a@mail.gmail.com>
Date:	Wed, 14 Nov 2007 19:00:44 +0530
From:	"Abhishek Sagar" <sagar.abhishek@...il.com>
To:	"Srinivasa Ds" <srinivasa@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, prasanna@...ibm.com,
	davem@...emloft.net, anil.s.keshavamurthy@...el.com,
	"Jim Keniston" <jkenisto@...ibm.com>,
	"Ananth N Mavinakayanahalli" <ananth@...ibm.com>
Subject: Re: [PATCH][RFC] kprobes: Add user entry-handler in kretprobes

On Nov 14, 2007 3:53 PM, Srinivasa Ds <srinivasa@...ibm.com> wrote:
> No, eventhough return instances are chained in an order, order of execution of
> return handler entirely depends on which process returns first

Right...the LIFO chain analogy holds true for return instances for the
same task only. As you've pointed out, kretprobe_instance is the only
thing that can bind corresponding entry and return handlers together,
which has been taken care of.

> So entry_handler() which gets executed last doesn't guarantee
> that its return handler will be executed first(because it took a lot time
> to return).

Only if there are return instances pending belonging to different tasks.

> So only thing to match the entry_handler() with its return_handler() is
> return probe instance(ri)'s address, which user has to take care explicitly

Lets see how entry and return handlers can be matched up in three
different scenarios:-

1. Multiple function entries from various tasks (the one you've just
pointed out).
2. Multiple kretprobe registration on the same function.
3. Nested calls of kretprobe'd function.

In cases 1 and 3, the following information can be used to match
corresponding entry and return handlers inside a user handler (if
needed):

(ri->task, ri->ret_addr)
where ri is struct kretprobe_instance *

This tuple should uniquely identify a return address (right?).


In case 2, entry and return handlers are anyways called in the right
order (taken care of by
trampoline_handler() due to LIFO insertion in ri->hlist).

The fact that ri is passed to both handlers should allow any user
handler to identify each of these cases and take appropriate
synchronization action pertaining to its private data, if needed.

> (Hence I feel sol a) would be nice).

With an entry-handler, any module aiming to profile running time of a
function (say) can simply do the following without being "return
instance" conscious. Note however that I'm not trying to address just
this scenario but trying to provide a general way to use
entry-handlers in kretprobes:

static unsigned  long flag = 0; /* use bit 0 as a global flag */
unsigned long long entry, exit;

int my_entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    if (!test_and_set_bit(0, &flag))
    /* this instance claims the first entry to kretprobe'd function */
        entry = sched_clock();
        /* do other stuff */
        return 0; /* right on! */
    }
    return 1; /* error: no return instance to be allocated for this
function entry */
}

/* will only be called iff flag == 1 */
int my_return_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
    BUG_ON(!flag);
    exit = sched_clock();
    set_bit(0, &flag);
}

I think something like this should do the trick for you.

> Thanks
>  Srinivasa DS

--
Thanks & Regards
Abhishek Sagar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists