This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Dynamic djprobe (and summary of Q&A)


Good summary. Please see my comments.

>-----Original Message-----
>From: Masami Hiramatsu [mailto:hiramatu@sdl.hitachi.co.jp] 

>A: First of all, the djprobe should be one of the dynamic 
>probes. 

Nobel goal.

>So my 
>answer is "NO". The marker is one of the static probes. I may consider 
>about the marker AFTER we implemented dynamic djprobe.

Sure, you can take that approach.

>
>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.

Okay, I take back and no issues here.



>
>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

Another important point to consider (in case of SMP) is 
3) Make sure none of the other CPU's are executing this area.


>I think we should have some discussions about the case of full 
>preemption.
Absolutely.


>Currently we can avoid that full preemption problem by changing 
>Kconfig.debug as below:
>config DJPROBE
>  bool "Direct Jump Probe"
>  depends on KPROBES && !PREEMPT

It would be good if you can avoid defining another config option.


>
>  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.

Sure, looking forward for your code to review.

Thanks,
Anil


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]