All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivasa Ds <srinivasa@in.ibm.com>
To: Abhishek Sagar <sagar.abhishek@gmail.com>
Cc: linux-kernel@vger.kernel.org, prasanna@in.ibm.com,
	davem@davemloft.net, anil.s.keshavamurthy@intel.com,
	Jim Keniston <jkenisto@us.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [PATCH][RFC] kprobes: Add user entry-handler in kretprobes
Date: Wed, 14 Nov 2007 13:27:41 +0530	[thread overview]
Message-ID: <473AAA75.2050900@in.ibm.com> (raw)
In-Reply-To: <863e9df20711130247g45d3d541j10c76434e9c65b00@mail.gmail.com>

Abhishek Sagar wrote:
> On Nov 13, 2007 12:09 AM, Abhishek Sagar <sagar.abhishek@gmail.com> wrote:
>> Whoops...sry for the repeated email..emailer trouble.
> 
> Expecting this one to makes it to the list. Summary again:
> 
> This patch introduces a provision to specify a user-defined callback
> to run at function entry to complement the return handler in
> kretprobes. Currently, whenever a kretprobe is registered, a user can
> specify a callback (return-handler) to be run each time the target
> function returns. This is also not guaranteed and is limited by the
> number of concurrently pending return instances of the target function
> in the current process's context.
> 
> This patch will now allow registration of another user defined handler
> which is guaranteed to run each time the current return instance is
> allocated and the return handler is set-up. Conversely, if the
> entry-handler returns an error, it'll cause the current return
> instance to be dropped and the return handler will also not run. The
> purpose is to provide flexibility to do certain kinds of function
> level profiling using kretprobes. By being able to register function
> entry and return handlers, kretprobes will now be able to reduce an
> extra probe registration (and associated race) for scenarios where an
> entry handler is required to capture the function call/entry event
> along with the corresponding function exit event.
> 

If I understand your intentions(to capture information on function call/entry and corresponding function exit) cleary, I have few concerns on this.

1) How do you map the entry_handler(which gets executed when a process enters the function) with each instance of return probe handler.
I accept that entry_handler() will execute each time process enters the function, but to  calculate time, one needs to know corresponding instance of return probe handler(there should be a map for each return handler). 

  Let me explain briefly.
Suppose in a SMP system, 4 processes  enter the same function at almost sametime(by executing entry_hanlder()) and returns from 4 different locations by executing the return handler.  Now how do I match entry_handler() with corresponding instance of return handler for calculating time.

Sometime back, Even I was interested in calculating the  function execution time, but I used approach a) .

Now What I think is, there could be 2 solutions to these problem.

a) Collect the entry time and exit time and put it in that kretprobe_instance structure and fetch it before freeing that instance.

b) Or pass ri(kretprobe_instance address to entry_handler) and match it with return probe handler.

  reply	other threads:[~2007-11-14  7:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <47389BEB.1000901@gmail.com>
2007-11-12 18:39 ` [PATCH][RFC] kprobes: Add user entry-handler in kretprobes Abhishek Sagar
2007-11-13 10:47   ` Abhishek Sagar
2007-11-14  7:57     ` Srinivasa Ds [this message]
2007-11-14  8:49       ` Abhishek Sagar
2007-11-14 10:23         ` Srinivasa Ds
2007-11-14 13:30           ` Abhishek Sagar
2007-11-14 22:51             ` Jim Keniston
2007-11-15 13:16               ` Abhishek Sagar
2007-11-15 21:16                 ` Jim Keniston
2007-11-16 17:50                   ` Abhishek Sagar
2007-11-17  0:54                     ` Jim Keniston
2007-11-17 18:15                       ` Abhishek Sagar
2007-11-19 12:26                       ` Abhishek Sagar
2007-11-21  5:55                         ` Jim Keniston
2007-11-21 10:20                           ` Abhishek Sagar
2007-11-27  0:54                             ` Jim Keniston
2007-11-15 15:00               ` Abhishek Sagar
2007-11-16  0:07                 ` Jim Keniston
2007-11-16 18:53                   ` Abhishek Sagar
2007-11-16 23:09                     ` Jim Keniston
2007-11-17 17:09                       ` Abhishek Sagar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=473AAA75.2050900@in.ibm.com \
    --to=srinivasa@in.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prasanna@in.ibm.com \
    --cc=sagar.abhishek@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.