Re: Hitachi djprobe mechanism

[Karim Yaghmour <karim@opersys.com>]

Satoshi Oshima wrote:
> As Masami answered in another thread, we need to divide the problem
> depending on the condition below:
> 
> 1) full preemptive kernel
> 2) voluntary or non preemptive kernel

Yes, I have seen this answer, and it is incomplete.

> But the case 2), we believe that we can expect currently
> sleeping process' stack only include EIPs which are limited
> address such as might_resched() or sched(). So djprobe user
> must not insert a probe to such point. In my understanding,
> voluntary or non preemption kernel doesn't try to preempt
> during interruption context.

But what about when the call that caused the resched came from higher
up the call tree and that it is that former call that is getting
squashed by the insertion of a jump on the instruction preceeding it.
The only way you could limit that is if you did a static analysis
and forbade any insertion of probes on any instruction preceeding
a call that _may_ result in a process scheduling ... Surely you see
this can't scale.

> In addition, all CPU run on bypass code after int3 bypass
> is created. (In another word, once int3 bypass would be set,
> all CPU never push replacing instruction address on it's stack)
> 
> So we need to take care of EIPs on current process of all CPUs
> and interrupt stack. Now we are implementing this check code,
> and we will provide soon.

But you have no way to figure out whether what you've found on the
stack is an address to some piece of code or just some valid data ...

> I know that problem. Current djprobe's helper script show
> disassemble code and prompt to avoid inserting a probe code
> into such place.
> 
> We may need to develop check function to avoid this problem,
> but it will be an userland tools. We expect that translator
> would provide these safety check, if possible.

So therefore, what this will do is, for each probe address candidate
for an instruction less than 5 bytes, it will go through all of the
kernel code to make sure that there are no references pointing to the
next instruction(s) ... ? This after having checked on process
stacks to make sure no one has a reference to those same addresses
while somehow figuring out whether what's being looked at is not
some data, but really a return address?

> Though djprobe has a few limitation, we believe that it is
> usefull for SystemTap project.

Like I said before, I can't stop anyone from working on anything,
so what I say here is really noise. Consider, though, that the
proposals being presented here seem to seriously increase in
complexity as more and more limitations of djprobe are explained,
and then weigh that in comparison to the real benefits in terms
of actual usage and general applicability.

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