This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Dynamic djprobe (and summary of Q&A)
- From: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- To: 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>
- Cc: 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: Sat, 30 Jul 2005 03:23:06 +0900
- Subject: Dynamic djprobe (and summary of Q&A)
Hi, all
There were many discussions after OLS. So, I would like to summarize
questions of the previous discussions and answer them as far as possible.
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.
Q: Should jump instruction be with in a page boundary to avoid access
violation and page fault?
A: My answer is NO. As far as I know, x86 processors can handle
non-aligned instructions correctly. We can see many non-aligned
instructions in the kernel binary. And, in the kernel space, there is no
page fault. Kernel code pages are always mapped to the kernel page
table. And Andi Kleen said “The CPU cancels and restarts the instruction
in this case and everything is atomic again.”
I think it is not necessary to care of page boundaries in x86
architecture. In the other architectures, I will consider about that
when I port djprobe. Please teach me, if you know something about that.
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 would like to answer each question individually.
1) I think the latest linux kernel does not aim for full preemption. It
aims for the voluntarily preemption. In the case of voluntarily
preemption, threads are scheduled from only limited addresses. So it is
easy to check that the preemption can not occur in the written area.
I think we should have some discussions about the case of full preemption.
Currently we can avoid that full preemption problem by changing
Kconfig.debug as below:
config DJPROBE
bool “Direct Jump Probe”
depends on KPROBES && !PREEMPT
Even in this case, you do not need to change your code. Because I can
provide a consistent djprobe interface that emulates djprobe by using
kprobe.
2) I have an idea for this problem. I am implementing this idea and
will post it in another mail. After that, please review the code.
Best Regards,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp