From: Prasanna S Panchamukhi <prasanna@in.ibm.com>
To: Jim Keniston <jkenisto@us.ibm.com>
Cc: Hien Nguyen <hien@us.ibm.com>,
SystemTAP <systemtap@sources.redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.12-rc1-mm3] [1/2] kprobes += function-return
Date: Tue, 12 Apr 2005 15:05:25 +0530 [thread overview]
Message-ID: <20050412093525.GC19538@in.ibm.com> (raw)
In-Reply-To: <1113242482.2298.128.camel@dyn9047018078.beaverton.ibm.com>
> > > int register_returnprobe(struct rprobe *rp) {
> > ...
> >
> > > independent of kprobe and jprobe.
> > ...
> > >
> > > make unregister exitprobes independent of kprobe/jprobe.
> > >
> > ...
> >
> > 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.)
>
> I suppose if pairing of entry and return probes is important for a user,
> he/she can always do the following:
>
> static int ready; // 1 = everybody registered
> // 2 = everybody knows we're registered
> ...
> ready = 0;
> ... register_kprobe(&kp)...
> ... register_retprobe(&rp) ...
> /* instant XXX -- see below*/
> ready = 1;
>
> and in kp.pre_handler do
> if (!ready) {
> // return probe not registered yet
> return 0;
> }
> ready = 2;
> <body of handler>
>
> and in rp.handler do
> if (ready != 2) {
> // Probed function entered during instant XXX,
> // so kp.pre_handler didn't act on it.
> return 0;
> }
> <body of handler>
>
> Keeping a whole group of kprobes, jprobes, and retprobes in the starting
> gate pending a "ready" signal (e.g., for SystemTap) could probably be
> handled similarly.
>
> Unregistration shouldn't be an issue. At any time you can have N active
> instances of the probed function, and have therefore recorded E entries
> and E-N returns. Hien's code handles all that on retprobe
> deregistration, but the user's instrumentation should never count on #
> probed entries == # probed returns.
>
Jim,
You can do something like you explained above to handle the pairing issues.
You need to provide simple and compact interfaces for return probe feature.
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>
prev parent reply other threads:[~2005-04-12 9:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-04 8:15 [PATCH 2.6.12-rc1-mm3] [1/2] kprobes += function-return Prasanna S Panchamukhi
2005-04-05 17:19 ` Jim Keniston
2005-04-11 18:01 ` Jim Keniston
2005-04-12 9:35 ` Prasanna S Panchamukhi [this message]
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=20050412093525.GC19538@in.ibm.com \
--to=prasanna@in.ibm.com \
--cc=hien@us.ibm.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=systemtap@sources.redhat.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.