This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Preemption-safe kprobe-booster(Re: [PATCH]kprobe booster for IA64)
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- Cc: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, SystemTAP <systemtap at sources dot redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, Jim Keniston <jkenisto at us dot ibm dot com>
- Date: Thu, 13 Jul 2006 20:25:17 +0900
- Subject: Re: Preemption-safe kprobe-booster(Re: [PATCH]kprobe booster for IA64)
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <4485223C.8090109@sdl.hitachi.co.jp> <20060628190541.A13874@unix-os.sc.intel.com> <44AAF207.7090908@sdl.hitachi.co.jp> <44B4952D.9010603@hitachi.com> <20060712010122.A30357@unix-os.sc.intel.com>
Hi, Anil
Thank you for precise advice.
Keshavamurthy Anil S wrote:
> On Wed, Jul 12, 2006 at 03:22:37PM +0900, Masami Hiramatsu wrote:
>> As far as we know, this function waits until all processes
>> are expired. And any preempted processes can't be expired, only
>> the processes who are scheduled by itself are expired.
>> This means these processes already left from kprobe's slots.
>> So, after that, we can release/reuse these slots safely.
> I am not sure about the behavior of the synchronized_sched() for
> preemptable kernels. When you say this function waits until
> all processes are expired, can this mean that process'es alloted time
> slot expired and hence it is scheduled out. If this is true,
> then it could very well happen that when we finish executing
> the original instruction in the booster buffer and just before
> jumping back to original code sequence, this process time slot
> can get expired and can be scheduled out and synchronize_sched()
> returns and you try to reuse the buffer :(
> Please confirm the behavior of synchroniz_sched() before going
> ahead and implementing the code.
I confirmed it and found that synchronize_sched() is an interface
to wait the RCU quiescent state. And the RCU quiescent state means;
- switch processes
- switch to user space
- idle state
As you say, it is not enough to ensure safety of kprobe-booster.
Now, we are searching for other good solutions against this problem.
Anyway, I'd like to disable booster when CONFIG_PREEMPT is defined
until this problem is solved. I attached the patch to this mail.
Please review it.
Thanks,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
kprobes.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --exclude=CVS -Narup a/arch/i386/kernel/kprobes.c b/arch/i386/kernel/kprobes.c
--- a/arch/i386/kernel/kprobes.c 2006-07-10 12:11:43.000000000 +0900
+++ b/arch/i386/kernel/kprobes.c 2006-07-10 15:41:17.000000000 +0900
@@ -256,11 +256,6 @@ static int __kprobes kprobe_handler(stru
int ret = 0;
kprobe_opcode_t *addr;
struct kprobe_ctlblk *kcb;
-#ifdef CONFIG_PREEMPT
- unsigned pre_preempt_count = preempt_count();
-#else
- unsigned pre_preempt_count = 1;
-#endif
addr = (kprobe_opcode_t *)(regs->eip - sizeof(kprobe_opcode_t));
@@ -338,13 +333,15 @@ static int __kprobes kprobe_handler(stru
return 1;
ss_probe:
- if (pre_preempt_count && p->ainsn.boostable == 1 && !p->post_handler){
+#ifdef CONFIG_PREEMPT
+ if (p->ainsn.boostable == 1 && !p->post_handler){
/* Boost up -- we can execute copied instructions directly */
reset_current_kprobe();
regs->eip = (unsigned long)p->ainsn.insn;
preempt_enable_no_resched();
return 1;
}
+#endif
prepare_singlestep(p, regs);
kcb->kprobe_status = KPROBE_HIT_SS;
return 1;