Re: [PATCH 2.6.12-rc1-mm3] [1/2] kprobes += function-return

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2005-04-05 at 10:19, Jim Keniston wrote:
> On Mon, 2005-04-04 at 01:15, Prasanna S Panchamukhi wrote:
> ...
> > int register_returnprobe(struct rprobe *rp) {
> ...
> 
> > independent of kprobe and jprobe.
> ...
> > 
> > make unregister exitprobes independent of kprobe/jprobe.
> > 
> ...
> > 
> > Please let me know if you need more information.
> > 
> > Thanks
> > Prasanna
> 
> We thought about that.  It is a nicer interface.  But I'm concerned that
> if the user has to do
> 	register_kprobe(&foo_entry_probe);
> 	register_retprobe(&foo_return_probe);
> then he/she has to be prepared to handle calls to foo that happen
> between register_kprobe and register_retprobe -- i.e., calls where the
> entry probe fires but the return probe doesn't.  Similarly on
> unregistration.
> 
> Here are a couple of things we could do to support registration and
> unregistration of retprobes that can be either dependent on or
> independent of the corresponding j/kprobes, as the user wants:
> 
> 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.)
> 
> OR
> 
> 2. Create the ability to (a) register kprobes, jprobes, and/or retprobes
> in a disabled state; and (b) enable a group of probes in an atomic
> operation.  Then you could register the entry and return probes
> independently, but enable them together.  We may need to do something
> like that for SystemTap anyway.
> 
> Jim Keniston
> IBM Linux Technology Center

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux