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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox