This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Satoshi Oshima <soshima at redhat dot com>
- To: karim at opersys dot com
- Cc: Richard J Moore <richardj_moore at uk dot ibm dot com>, systemtap at sources dot redhat dot com, Andi Kleen <ak at suse dot de>, Mathieu Desnoyers <compudj at krystal dot dyndns dot org>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, michel dot dagenais at polymtl dot ca, Roland McGrath <roland at redhat dot com>, sugita at sdl dot hitachi dot co dot jp
- Date: Mon, 01 Aug 2005 18:12:27 -0400
- Subject: Re: Hitachi djprobe mechanism
- References: <OF331D042E.CCADD212-ON41257050.002DC63A-41257050.002F8168@uk.ibm.com> <42EE7E97.7080501@redhat.com> <42EE86AD.609@opersys.com>
Thank you for your comment.
Karim Yaghmour wrote:
Satoshi Oshima wrote:
step 2: safety check;
make sure that all CPUs don't run on the code that will
be replaced with jmp instruction (also check whether stack
include EIP of the code which is subject to replace)
Please explain exactly how you will make sure that there is no pre-existing
reference to any of the replaced instructions, whether it be on the stack
or elsewhere. Consider a system that has many thousands of processes running
in parallel on different CPUs.
> Also consider that you may find things on the stack that look like
address
> references to the range you wish to replace, but are actually valid data.
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
When they select 1), djprobe cannot be applied currently.
So we decided that djprobe functionality will be off by
Kconfig (be replaced with kprobe).
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.
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.
step 3: (after all CPU pass safety check) replace with jmp
instruction without first byte. leave int 3 instruction
unchanged at this time (new step).
This still fails to cover the very simple case I explained earlier:
if (...)
goto label;
<more code>
single_byte_asm_instruction_code();
label:
foo();
You still can't replace the instruction right before the label, and you'd
have to have an integrated disassembler to go through all the code and
make sure it too doesn't have a reference to the address of "label:".
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.
Though djprobe has a few limitation, we believe that it is
usefull for SystemTap project.
In as far as I can see, it remains that the only safe way to use djprobe
is to not touch any instruction that is less than 5 bytes, that's if
there aren't other limitations as I mentioned earlier.
Karim
Satoshi