This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
[RFC PATCH 0/3] Djprobe improvement patches (Re: Dynamic djprobe)
- From: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- To: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- Cc: systemtap at sources dot redhat dot com,"Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>,Roland McGrath <roland at redhat dot com>,Richard J Moore <richardj_moore at uk dot ibm dot com>, Andi Kleen <ak at muc dot de>,michel dot dagenais at polymtl dot ca,Mathieu Desnoyers <compudj at krystal dot dyndns dot org>,"Frank Ch. Eigler" <fche at redhat dot com>,Karim Yaghmour <karim at opersys dot com>,Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>,Yumiko Sugita <sugita at sdl dot hitachi dot co dot jp>
- Date: Wed, 03 Aug 2005 02:07:18 +0900
- Subject: [RFC PATCH 0/3] Djprobe improvement patches (Re: Dynamic djprobe)
- References: <42EA740A.10601@sdl.hitachi.co.jp>
Hi,
Yesterday Satoshi explained the following improvement ideas.
Satoshi Oshima wrote:
> And we believe that djprobe can safely modify the code like this;
>
> step 1: making int3 bypass code using kprobe
>
> 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)
>
> 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).
>
> step 4: i-cache flush or serializing:
> invoke i-cache flush instruction such as CLFLASH or serialize
> instruction such as CPUID on all CPUs (new step)
>
> step 5: (after all CPU invoke i-cache flush or serializing instruction)
> replace int 3 instruction with first byte of jmp instruction
I attempt to solve some problems based on these improvements by the
following series of patches.
I organized problems as below.
1) Djprobe currently works on non (or voluntary)-preemptive kernel. So,
djprobe should be disabled when CONFIG_PREEMPT is enabled. (This was
described in my previous mail)
2) Nested interrupts hide true executing address into current thread’s
stack. So, we find it and check this address is in safe area. (step 2:
safety check )
3) To avoid GPF, we should be serialize or flush i-cache on each CPU.
(step 4: i-cache flush or serializing)
I developed 3 patches to solve these problems.
Also, I and Satoshi think there is another method:
Stop all CPUs until whole instructions are replaced instead of using bypass.
I’m developing this patch too. After developed, I will send it.
Best regards,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp