Dynamic djprobe (and summary of Q&A)

Masami Hiramatsu hiramatu@sdl.hitachi.co.jp
Fri Jul 29 18:23:00 GMT 2005


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



More information about the Systemtap mailing list