Re: Dynamic djprobe (and summary of Q&A)

[Karim Yaghmour <karim at opersys dot com>]

Masami Hiramatsu wrote:
> Q: Does djprobe needs some kinds of marker?
> A: First of all, the djprobe should be one of the dynamic probes. So my 
> answer is “NO”. The marker is one of the static probes. I may consider 
> about the marker AFTER we implemented dynamic djprobe.

Your choice to consider before or after. Note, though, that the topic of
markers goes far beyond systemtap, or any other probing/tracing mechanism.
And, as such, progress is not really gated by adoption by djprobe, systemtap,
lkst, or anything else for that matter. It just so happens that the
systemtap list was chosen to initiate discussion of this mechanism since
those that attended the markers "bof" were moslty folks that had just
attented the systemtap bof.

> Q: How to guarantee no threads are executing the written area? EIP may 
> be stored in the stack memory of those threads.
> A: I think there are two problems:
>   1) Problem caused by preemption
>   2) Problem caused by Interruption

I think the problem is actually larger than this. How about this
bit of code:

	if (...)
		goto label;
	<more code>
	single_byte_asm_instruction_code();
label:
	foo();

I just don't see how there's going to be any implementation of djprobe
that is going to stop the insertion of a jmp in place of the instruction
right before the above label without causing an instruction trap on the
CPU once another piece of code in the kernel does the if-goto path ...
lest you actually implement another bit of code that parses through
assembly to find all references to "label:" and change those too ...
but it should be obvious that this isn't going to scale.

Also consider if you just have something like:
	single_byte_asm_instruction_code();
	foo();

And within foo() some process scheduling happened (not preemption or
interrupt). What then when the process comes back alive and some bit
of code in the kernel returns?

But let me take this even further. Say, after much discussion, those
still interested in promoting this mechanism actually came up with a
set of guidelines of where and when djprobe can or cannot be used.
Having done that, what chances are there that these guidelines will
be uniformly applicable accross the different architectures supported
by Linux (in fact they likely won't)? Even if we were willing to
forfit that, then how are messages such as "cannot insert probe point
at address XYZ because of your architectures' limitations, please
choose another location" going to be helpful to users?

Maybe I just don't understand what you're trying to achieve, and in that
case, I'd be more than happy to recognize the usefullness of this
mechanism. From reading the kerninst paper, though, it seems rather
clear that even these guys understood the limitations ... "there is no
guarantee that only a single instruction is overwritten when splicing
(x86)".

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546