* RE: [PATCH] Kprobes- robust fault handling for i386 @ 2006-02-24 19:17 Keshavamurthy, Anil S 2006-02-27 9:24 ` Prasanna S Panchamukhi 0 siblings, 1 reply; 7+ messages in thread From: Keshavamurthy, Anil S @ 2006-02-24 19:17 UTC (permalink / raw) To: prasanna; +Cc: systemtap Prasanna, For better review comments, can you please split your patch into following, currently finding it hard to follow the kprobes states. 1) [PATCH]Fault handling due to calling pre_handler 2) [PATCH]Fault handling due to calling post_handler 3) [PATCH]Fault handling due to single_stepping 4) [PATCH]Fault handling due to single_stepping reentrant probe Patches 3 and 4 above are required only to support user probes, so for now I think you can skip them. Also another suggesting, rename the kprobes states to something more meaning full. Say KPROBE_IN_PRE_HANDLER - This states indicates we are calling pre_handler KPROBE_IN_POST_HANDLER - This states indicates we are calling post_handler KPROBES_IN_SS - We are trying to single step KPROBES_IN_REENTER_SS - We are trying to single step reentrant probes [...] Thanks, -Anil Keshavamurthy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 2006-02-24 19:17 [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy, Anil S @ 2006-02-27 9:24 ` Prasanna S Panchamukhi 2006-02-27 9:25 ` [PATCH] Kprobes- robust fault handling for i386 post_handler changes Prasanna S Panchamukhi 2006-02-28 1:02 ` [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy Anil S 0 siblings, 2 replies; 7+ messages in thread From: Prasanna S Panchamukhi @ 2006-02-27 9:24 UTC (permalink / raw) To: Keshavamurthy, Anil S; +Cc: systemtap Anil, On Fri, Feb 24, 2006 at 11:17:01AM -0800, Keshavamurthy, Anil S wrote: > Prasanna, > For better review comments, can you please split your patch > into following, currently finding it hard to follow the kprobes states. > 1) [PATCH]Fault handling due to calling pre_handler > 2) [PATCH]Fault handling due to calling post_handler > 3) [PATCH]Fault handling due to single_stepping > 4) [PATCH]Fault handling due to single_stepping reentrant probe > > Patches 3 and 4 above are required only to support user probes, > so for now I think you can skip them. For your convenience I have splitup the patches, please find then below. In general splitting of patches is a good idea, but here I think splitting does not make much difference, since post_handler changes are only few lines. Correct me if I am wrong. > > Also another suggesting, rename the kprobes states to something more > meaning full. Say > KPROBE_IN_PRE_HANDLER - This states indicates we are calling pre_handler > KPROBE_IN_POST_HANDLER - This states indicates we are calling > post_handler > KPROBES_IN_SS - We are trying to single step > KPROBES_IN_REENTER_SS - We are trying to single step reentrant probes > [...] > Renaming states is a good idea, but we should do it independent of fault handling. So how about doing it once we have robust fault handling in place. Thanks Prasanna This patch provides proper kprobes fault handling, if a user-specified pre handlers tries to access user address space, through copy_from_user(), get_user() etc. The user-specified fault handler gets called only if the fault occurs wile executing user-specified handlers. In such a case user-specified handler is allowed to fix it first, later if the user-specifed fault handler does not fix it, we try to fix it by calling fix_exception(). Also we set the "FAULTED" flags if user-specified pre handler faults, so that corresponding user-specified post_handler can be skipped. The user-specified handler will not be called if the fault happens when single stepping the original instruction, instead we reset the current probe and allow the system page fault handler to fix it up. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> arch/i386/kernel/kprobes.c | 73 ++++++++++++++++++++++++++++++++++++++------- include/linux/kprobes.h | 12 +++++++ 2 files changed, 75 insertions(+), 10 deletions(-) diff -puN arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling arch/i386/kernel/kprobes.c --- linux-2.6.16-rc4-mm2/arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling 2006-02-27 13:58:41.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/arch/i386/kernel/kprobes.c 2006-02-27 14:08:45.000000000 +0530 @@ -35,6 +35,7 @@ #include <asm/cacheflush.h> #include <asm/kdebug.h> #include <asm/desc.h> +#include <asm/uaccess.h> void jprobe_return_end(void); @@ -232,8 +233,9 @@ static int __kprobes kprobe_handler(stru if (kprobe_running()) { p = get_kprobe(addr); if (p) { - if (kcb->kprobe_status == KPROBE_HIT_SS && - *p->ainsn.insn == BREAKPOINT_INSTRUCTION) { + if (((kcb->kprobe_status == KPROBE_HIT_SS) || + (kcb->kprobe_status == KPROBE_HIT_FAULT_SS)) && + (*p->ainsn.insn == BREAKPOINT_INSTRUCTION)) { regs->eflags &= ~TF_MASK; regs->eflags |= kcb->kprobe_saved_eflags; goto no_kprobe; @@ -320,7 +322,10 @@ static int __kprobes kprobe_handler(stru ss_probe: prepare_singlestep(p, regs); - kcb->kprobe_status = KPROBE_HIT_SS; + if (kcb->kprobe_status != KPROBE_HIT_FAULT) + kcb->kprobe_status = KPROBE_HIT_SS; + else + kcb->kprobe_status = KPROBE_HIT_FAULT_SS; return 1; no_kprobe: @@ -554,15 +559,63 @@ static inline int kprobe_fault_handler(s struct kprobe *cur = kprobe_running(); struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); - if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) - return 1; - - if (kcb->kprobe_status & KPROBE_HIT_SS) { - resume_execution(cur, regs, kcb); + switch(kcb->kprobe_status) { + case KPROBE_HIT_SS: + case KPROBE_REENTER: + case KPROBE_HIT_FAULT_SS: + /* + * We are here because the instruction being single + * stepped caused a page fault. We reset the current + * kprobe and the eip points back to the probe address + * and allow the page fault handler to continue as a + * normal page fault. + */ + regs->eip = (unsigned long)cur->addr; regs->eflags |= kcb->kprobe_old_eflags; - - reset_current_kprobe(); + if (kcb->kprobe_status == KPROBE_REENTER) + restore_previous_kprobe(kcb); + else + reset_current_kprobe(); preempt_enable_no_resched(); + break; + case KPROBE_HIT_ACTIVE: + /* + * We set the status as "FAULTED", so that subsequent + * user specified post handler can be avoided. + */ + kcb->kprobe_status = KPROBE_HIT_FAULT; + /*fixup the exception*/ + /* + * We increment the nmissed count for accounting, + * we can also use npre/npostfault count for accouting + * these specific fault cases. + */ + kprobes_inc_nmissed_count(cur); + + /* + * We come here because instructions in the pre/post + * handler caused the page_fault, this could happen + * if handler tries to access user space by + * copy_from_user(), get_user() etc. Let the + * user-specified handler try to fix it first. + */ + if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) + return 1; + + /* + * In case the user-specified fault handler returned + * zero, try to fix up. + */ + if (fixup_exception(regs)) + return 1; + + /* + * fixup_exception() could not handle it, + * Let do_page_fault() fix it. + */ + break; + default: + break; } return 0; } diff -puN include/linux/kprobes.h~kprobes-i386-pagefault-handling include/linux/kprobes.h --- linux-2.6.16-rc4-mm2/include/linux/kprobes.h~kprobes-i386-pagefault-handling 2006-02-27 13:58:41.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/include/linux/kprobes.h 2006-02-27 13:58:42.000000000 +0530 @@ -46,6 +46,18 @@ #define KPROBE_HIT_SS 0x00000002 #define KPROBE_REENTER 0x00000004 #define KPROBE_HIT_SSDONE 0x00000008 +/* + * When set, signifies that the fault happened + * while in the user-specified pre_handler. + */ +#define KPROBE_HIT_FAULT 0x00000010 +/* + * When set, signifies that the faulted user-specified + * pre_handler has been executed, now allow single + * stepping of original instruction and dont execute + * the post_handler after single stepping. + */ +#define KPROBE_HIT_FAULT_SS 0x00000020 /* Attach to insert probes on any functions which should be ignored*/ #define __kprobes __attribute__((__section__(".kprobes.text"))) _ -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 post_handler changes 2006-02-27 9:24 ` Prasanna S Panchamukhi @ 2006-02-27 9:25 ` Prasanna S Panchamukhi 2006-02-28 1:02 ` [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy Anil S 1 sibling, 0 replies; 7+ messages in thread From: Prasanna S Panchamukhi @ 2006-02-27 9:25 UTC (permalink / raw) To: Keshavamurthy, Anil S; +Cc: systemtap This patch provides proper kprobes fault handling, if a user-specified post handlers tries to access user address space, through copy_from_user(), get_user() etc. The user-specified fault handler gets called only if the fault occurs wile executing user-specified handlers. In such a case user-specified handler is allowed to fix it first, later if the user-specifed fault handler does not fix it, we try to fix it by calling fix_exception(). The user-specified handler will not be called if the fault happens when single stepping the original instruction, instead we reset the current probe and allow the system page fault handler to fix it up. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> arch/i386/kernel/kprobes.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletion(-) diff -puN arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling-post_handler arch/i386/kernel/kprobes.c --- linux-2.6.16-rc4-mm2/arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling-post_handler 2006-02-27 13:59:13.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/arch/i386/kernel/kprobes.c 2006-02-27 14:01:50.000000000 +0530 @@ -526,7 +526,9 @@ static inline int post_kprobe_handler(st if (!cur) return 0; - if ((kcb->kprobe_status != KPROBE_REENTER) && cur->post_handler) { + if ((kcb->kprobe_status != KPROBE_REENTER) + && (kcb->kprobe_status != KPROBE_HIT_FAULT_SS) + && cur->post_handler) { kcb->kprobe_status = KPROBE_HIT_SSDONE; cur->post_handler(cur, regs, 0); } @@ -585,6 +587,7 @@ static inline int kprobe_fault_handler(s */ kcb->kprobe_status = KPROBE_HIT_FAULT; /*fixup the exception*/ + case KPROBE_HIT_SSDONE: /* * We increment the nmissed count for accounting, * we can also use npre/npostfault count for accouting _ -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 2006-02-27 9:24 ` Prasanna S Panchamukhi 2006-02-27 9:25 ` [PATCH] Kprobes- robust fault handling for i386 post_handler changes Prasanna S Panchamukhi @ 2006-02-28 1:02 ` Keshavamurthy Anil S 2006-02-28 14:37 ` Prasanna S Panchamukhi 1 sibling, 1 reply; 7+ messages in thread From: Keshavamurthy Anil S @ 2006-02-28 1:02 UTC (permalink / raw) To: Prasanna S Panchamukhi; +Cc: Keshavamurthy, Anil S, systemtap On Mon, Feb 27, 2006 at 02:55:35PM +0530, Prasanna S Panchamukhi wrote: > Anil, > > > For your convenience I have splitup the patches, please find > then below. Thanks for the splitting. > In general splitting of patches is a good idea, but here I think > splitting does not make much difference, since post_handler changes > are only few lines. Correct me if I am wrong. Since you are introducing lots of kprobes states it is good to split the patches according the pre/post/ss handling as the reviewer can understand why each kprobes state is needed. Remember the lesser the states easier to understand. > > Renaming states is a good idea, but we should do it independent of fault > handling. So how about doing it once we have robust fault handling in > place. Sure, can be done later too. > > Over all the the logic seems to good, except I did not did not see where you are handling multiple sequenital faults that can happen in pre/post handler. i.e once the fault happens in say pre_handler, then the status goes to KPROBE_HIT_FAULT, and say this fault is recovered and the pre_handler continues and again before returning from pre_handler their can be another fault and this fault is not being handed currently. Also I did not see why you are not changing the status back to original status if the fault is recovered properly. i.e KPROBE_HIT_ACTIVE -> KPROBE_HIT_FAULT. In KPROBE_HIT_FAULT state if this recovers, why not change this back to KPROBE_HIT_ACTIVE? Anyreason for not doing this? -Anil ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 2006-02-28 1:02 ` [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy Anil S @ 2006-02-28 14:37 ` Prasanna S Panchamukhi 2006-02-28 20:25 ` Keshavamurthy Anil S 0 siblings, 1 reply; 7+ messages in thread From: Prasanna S Panchamukhi @ 2006-02-28 14:37 UTC (permalink / raw) To: Keshavamurthy Anil S; +Cc: systemtap Anil, Thanks for your review comments. Please see the updated patch below, this patch is only for i386 architecture and once we are ok with it, we will port it to other architectures. > > > Over all the the logic seems to good, except I did not > did not see where you are handling multiple sequenital faults > that can happen in pre/post handler. i.e once the fault happens > in say pre_handler, then the status goes to KPROBE_HIT_FAULT, > and say this fault is recovered and the pre_handler continues and > again before returning from pre_handler their can be another fault > and this fault is not being handed currently. The patch below takes care of multiple faults within the same pre/post_handler. > Also I did not see why you are not changing the status back to > original status if the fault is recovered properly. i.e > KPROBE_HIT_ACTIVE -> KPROBE_HIT_FAULT. In KPROBE_HIT_FAULT state > if this recovers, why not change this back to KPROBE_HIT_ACTIVE? > Anyreason for not doing this? > The only reason was to avoid post_handler being executed in case if the user-defined pre-handler faulted. Now the patch below avoids corresponding user-defined post_handler without introducing any new state. The main reason to avoid post_handler execution in this case is to avoid any incosistant data references between pre and post handlers. Thanks Prasanna This patch provides proper kprobes fault handling, if a user-specified pre/post handlers tries to access user address space, through copy_from_user(), get_user() etc. The user-specified fault handler gets called only if the fault occurs while executing user-specified handlers. In such a case user-specified handler is allowed to fix it first, later if the user-specifed fault handler does not fix it, we try to fix it by calling fix_exception(). Also we set the "kprobe_faulted" instance if user-specified pre handler faults, so that corresponding user-specified post_handler can be skipped. The user-specified handler will not be called if the fault happens when single stepping the original instruction, instead we reset the current probe and allow the system page fault handler to fix it up. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> arch/i386/kernel/kprobes.c | 66 +++++++++++++++++++++++++++++++++++++++------ include/asm-i386/kprobes.h | 1 kernel/kprobes.c | 14 ++++++++- 3 files changed, 72 insertions(+), 9 deletions(-) diff -puN include/asm-i386/kprobes.h~kprobes-i386-pagefault-handling include/asm-i386/kprobes.h --- linux-2.6.16-rc4-mm2/include/asm-i386/kprobes.h~kprobes-i386-pagefault-handling 2006-02-28 18:00:20.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/include/asm-i386/kprobes.h 2006-02-28 18:01:16.000000000 +0530 @@ -74,6 +74,7 @@ struct kprobe_ctlblk { long *jprobe_saved_esp; struct pt_regs jprobe_saved_regs; kprobe_opcode_t jprobes_stack[MAX_STACK_SIZE]; + struct kprobe *kprobe_faulted; struct prev_kprobe prev_kprobe; }; diff -puN arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling arch/i386/kernel/kprobes.c --- linux-2.6.16-rc4-mm2/arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling 2006-02-28 09:47:48.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/arch/i386/kernel/kprobes.c 2006-02-28 19:34:20.000000000 +0530 @@ -35,6 +35,7 @@ #include <asm/cacheflush.h> #include <asm/kdebug.h> #include <asm/desc.h> +#include <asm/uaccess.h> void jprobe_return_end(void); @@ -523,7 +524,8 @@ static inline int post_kprobe_handler(st if ((kcb->kprobe_status != KPROBE_REENTER) && cur->post_handler) { kcb->kprobe_status = KPROBE_HIT_SSDONE; - cur->post_handler(cur, regs, 0); + if (kcb->kprobe_faulted != cur) + cur->post_handler(cur, regs, 0); } resume_execution(cur, regs, kcb); @@ -554,15 +556,63 @@ static inline int kprobe_fault_handler(s struct kprobe *cur = kprobe_running(); struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); - if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) - return 1; - - if (kcb->kprobe_status & KPROBE_HIT_SS) { - resume_execution(cur, regs, kcb); + switch(kcb->kprobe_status) { + case KPROBE_HIT_SS: + case KPROBE_REENTER: + /* + * We are here because the instruction being single + * stepped caused a page fault. We reset the current + * kprobe and the eip points back to the probe address + * and allow the page fault handler to continue as a + * normal page fault. + */ + regs->eip = (unsigned long)cur->addr; regs->eflags |= kcb->kprobe_old_eflags; - - reset_current_kprobe(); + if (kcb->kprobe_status == KPROBE_REENTER) + restore_previous_kprobe(kcb); + else + reset_current_kprobe(); preempt_enable_no_resched(); + break; + case KPROBE_HIT_ACTIVE: + /* + * Set appropriate kprobe instance, so that corresponding + * post_handler can be skipped in order to avoid any + * inconsistant data. + */ + kcb->kprobe_faulted = cur; + case KPROBE_HIT_SSDONE: + /* + * We increment the nmissed count for accounting, + * we can also use npre/npostfault count for accouting + * these specific fault cases. + */ + kprobes_inc_nmissed_count(cur); + + /* + * We come here because instructions in the pre/post + * handler caused the page_fault, this could happen + * if handler tries to access user space by + * copy_from_user(), get_user() etc. Let the + * user-specified handler try to fix it first. + */ + if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) + return 1; + + /* + * In case the user-specified fault handler returned + * zero, try to fix up. + */ + if (fixup_exception(regs)) + return 1; + + /* + * fixup_exception() could not handle it, + * Let do_page_fault() fix it. + */ + break; + default: + break; } return 0; } diff -puN kernel/kprobes.c~kprobes-i386-pagefault-handling kernel/kprobes.c --- linux-2.6.16-rc4-mm2/kernel/kprobes.c~kprobes-i386-pagefault-handling 2006-02-28 18:04:09.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/kernel/kprobes.c 2006-02-28 19:27:33.000000000 +0530 @@ -208,9 +208,14 @@ static void __kprobes aggr_post_handler( unsigned long flags) { struct kprobe *kp; + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); list_for_each_entry_rcu(kp, &p->list, list) { - if (kp->post_handler) { + /* + * Check if the corresponding pre_handler had faulted, avoid + * the post_handler in such a case. + */ + if (kp->post_handler && (kcb->kprobe_faulted != kp)) { set_kprobe_instance(kp); kp->post_handler(kp, regs, flags); reset_kprobe_instance(); @@ -223,12 +228,19 @@ static int __kprobes aggr_fault_handler( int trapnr) { struct kprobe *cur = __get_cpu_var(kprobe_instance); + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); /* * if we faulted "during" the execution of a user specified * probe handler, invoke just that probe's fault handler */ if (cur && cur->fault_handler) { + /* + * Set kprobe_faulted to appropriate kprobe instance, so that + * corresponding post handler can be skipped if the fault + * happened due to pre_handler. + */ + kcb->kprobe_faulted = cur; if (cur->fault_handler(cur, regs, trapnr)) return 1; } _ -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 2006-02-28 14:37 ` Prasanna S Panchamukhi @ 2006-02-28 20:25 ` Keshavamurthy Anil S 2006-03-01 14:49 ` Prasanna S Panchamukhi 0 siblings, 1 reply; 7+ messages in thread From: Keshavamurthy Anil S @ 2006-02-28 20:25 UTC (permalink / raw) To: Prasanna S Panchamukhi; +Cc: Keshavamurthy, Anil S, systemtap On Tue, Feb 28, 2006 at 06:38:36AM -0800, Prasanna S Panchamukhi wrote: > > Anil, > > Thanks for your review comments. Please see the updated patch > below, this patch is only for i386 architecture and once > we are ok with it, we will port it to other architectures. This version looks good with no new Kprobes states. Makes life easy to understand :-) > [..]The main reason to avoid post_handler execution in this > case is to avoid any incosistant data references between pre and post > handlers. Okay, I got that point, but if the fault recovery in pre_handler is *successful*, then in this case you *should* permit calling post_handler. See my inline comments to address this issue. Thanks, Anil > > Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> > > arch/i386/kernel/kprobes.c | 66 > +++++++++++++++++++++++++++++++++++++++------ > include/asm-i386/kprobes.h | 1 > kernel/kprobes.c | 14 ++++++++- > 3 files changed, 72 insertions(+), 9 deletions(-) > > diff -puN include/asm-i386/kprobes.h~kprobes-i386-pagefault-handling > include/asm-i386/kprobes.h > --- > linux-2.6.16-rc4-mm2/include/asm-i386/kprobes.h~kprobes-i386-pagefault > -handling 2006-02-28 18:00:20.000000000 +0530 > > +++ linux-2.6.16-rc4-mm2-prasanna/include/asm-i386/kprobes.h > 2006-02-28 18:01:16.000000000 +0530 > @@ -74,6 +74,7 @@ struct kprobe_ctlblk { > long *jprobe_saved_esp; > struct pt_regs jprobe_saved_regs; > kprobe_opcode_t jprobes_stack[MAX_STACK_SIZE]; > + struct kprobe *kprobe_faulted; > struct prev_kprobe prev_kprobe; > }; Good approach. > > diff -puN arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling > arch/i386/kernel/kprobes.c > --- > linux-2.6.16-rc4-mm2/arch/i386/kernel/kprobes.c~kprobes-i386-pagefault > -handling 2006-02-28 09:47:48.000000000 +0530 > > +++ linux-2.6.16-rc4-mm2-prasanna/arch/i386/kernel/kprobes.c > 2006-02-28 19:34:20.000000000 +0530 > @@ -35,6 +35,7 @@ > #include <asm/cacheflush.h> > #include <asm/kdebug.h> > #include <asm/desc.h> > +#include <asm/uaccess.h> > > void jprobe_return_end(void); > > @@ -523,7 +524,8 @@ static inline int post_kprobe_handler(st > > if ((kcb->kprobe_status != KPROBE_REENTER) && > cur->post_handler) { > kcb->kprobe_status = KPROBE_HIT_SSDONE; > - cur->post_handler(cur, regs, 0); > + if (kcb->kprobe_faulted != cur) > + cur->post_handler(cur, regs, 0); > } > > resume_execution(cur, regs, kcb); > @@ -554,15 +556,63 @@ static inline int kprobe_fault_handler(s > struct kprobe *cur = kprobe_running(); > struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); > > - if (cur->fault_handler && cur->fault_handler(cur, regs, > trapnr)) > - return 1; > - > - if (kcb->kprobe_status & KPROBE_HIT_SS) { > - resume_execution(cur, regs, kcb); > + switch(kcb->kprobe_status) { > + case KPROBE_HIT_SS: > + case KPROBE_REENTER: > + /* > + * We are here because the instruction being single > + * stepped caused a page fault. We reset the current > + * kprobe and the eip points back to the probe address > + * and allow the page fault handler to continue as a > + * normal page fault. > + */ > + regs->eip = (unsigned long)cur->addr; > regs->eflags |= kcb->kprobe_old_eflags; > - > - reset_current_kprobe(); > + if (kcb->kprobe_status == KPROBE_REENTER) > + restore_previous_kprobe(kcb); > + else > + reset_current_kprobe(); > preempt_enable_no_resched(); > + break; > + case KPROBE_HIT_ACTIVE: > + /* > + * Set appropriate kprobe instance, so that > corresponding > + * post_handler can be skipped in order to avoid any > + * inconsistant data. > + */ > + kcb->kprobe_faulted = cur; > + case KPROBE_HIT_SSDONE: > + /* > + * We increment the nmissed count for accounting, > + * we can also use npre/npostfault count for accouting > + * these specific fault cases. > + */ > + kprobes_inc_nmissed_count(cur); > + > + /* > + * We come here because instructions in the pre/post > + * handler caused the page_fault, this could happen > + * if handler tries to access user space by > + * copy_from_user(), get_user() etc. Let the > + * user-specified handler try to fix it first. > + */ > + if (cur->fault_handler && cur->fault_handler(cur, > regs, trapnr)) > + return 1; if the fault recovery is successful, before returning 1, you need to reset kcb->kprobe_faulted to NULL; > + > + /* > + * In case the user-specified fault handler returned > + * zero, try to fix up. > + */ > + if (fixup_exception(regs)) > + return 1; same here, before returning 1, you need to reset kcb->kprobe_faulted to NULL; > + > + /* > + * fixup_exception() could not handle it, > + * Let do_page_fault() fix it. > + */ > + break; > + default: > + break; > } > return 0; > } > diff -puN kernel/kprobes.c~kprobes-i386-pagefault-handling > kernel/kprobes.c > --- > linux-2.6.16-rc4-mm2/kernel/kprobes.c~kprobes-i386-pagefault-handling > 2006-02-28 18:04:09.000000000 +0530 > +++ linux-2.6.16-rc4-mm2-prasanna/kernel/kprobes.c 2006-02-28 > 19:27:33.000000000 +0530 > @@ -208,9 +208,14 @@ static void __kprobes aggr_post_handler( > unsigned long flags) > { > struct kprobe *kp; > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); > > list_for_each_entry_rcu(kp, &p->list, list) { > - if (kp->post_handler) { > + /* > + * Check if the corresponding pre_handler had faulted, > avoid > + * the post_handler in such a case. > + */ > + if (kp->post_handler && (kcb->kprobe_faulted != kp)) { > set_kprobe_instance(kp); > kp->post_handler(kp, regs, flags); > reset_kprobe_instance(); > @@ -223,12 +228,19 @@ static int __kprobes aggr_fault_handler( > int trapnr) > { > struct kprobe *cur = __get_cpu_var(kprobe_instance); > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); > > /* > * if we faulted "during" the execution of a user specified > * probe handler, invoke just that probe's fault handler > */ > if (cur && cur->fault_handler) { > + /* > + * Set kprobe_faulted to appropriate kprobe instance, > so that > + * corresponding post handler can be skipped if the > fault > + * happened due to pre_handler. > + */ > + kcb->kprobe_faulted = cur; Move this kcb->kprobe_faulted = cur; before if(curr && cur->handler) {} The reason is, irrespective of cur->fault_handler, we need to save kcb->kprobe_faulted, so post handler can be skipped properly. > if (cur->fault_handler(cur, regs, trapnr)) > return 1; > } > > _ > -- > Prasanna S Panchamukhi > Linux Technology Center > India Software Labs, IBM Bangalore > Email: prasanna@in.ibm.com > Ph: 91-80-51776329 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Kprobes- robust fault handling for i386 2006-02-28 20:25 ` Keshavamurthy Anil S @ 2006-03-01 14:49 ` Prasanna S Panchamukhi 0 siblings, 0 replies; 7+ messages in thread From: Prasanna S Panchamukhi @ 2006-03-01 14:49 UTC (permalink / raw) To: Keshavamurthy Anil S; +Cc: systemtap On Tue, Feb 28, 2006 at 12:25:26PM -0800, Keshavamurthy Anil S wrote: > On Tue, Feb 28, 2006 at 06:38:36AM -0800, Prasanna S Panchamukhi wrote: > > > > Anil, > > > > Thanks for your review comments. Please see the updated patch > > below, this patch is only for i386 architecture and once > > we are ok with it, we will port it to other architectures. > This version looks good with no new Kprobes states. > Makes life easy to understand :-) > > > [..]The main reason to avoid post_handler execution in this > > case is to avoid any incosistant data references between pre and post > > handlers. > Okay, I got that point, but if the fault recovery in pre_handler > is *successful*, then in this case you *should* permit calling > post_handler. See my inline comments to address this issue. Anil, To skip post_handler execution for unsuccessful fault recovery in the pre_hanlder, we need to take several things like aggrigate kprobe handlers, using the same kprobe structures across the same probe hit on different cpus at the same time etc. This restricts us from avoiding execution of the post-handler in case of unsuccessful fault recovery. Please find the patch below that allows post-handler execution in all cases as of now. Thanks Prasanna This patch provides proper kprobes fault handling, if a user-specified pre/post handler tries to access user address space, because of copy_from_user(), get_user() etc. The user-specified fault handler gets called only if the fault occurs while executing user-specified handler. In such a case user-specified handler is allowed to fix it first. If it is unsuccessful, we try to fix it by calling fixup_exception(). The user-specified handler will not be called if the fault happened when single stepping the original instruction, instead we reset the current probe and allow the system page fault handler to handle it. Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> arch/i386/kernel/kprobes.c | 57 +++++++++++++++++++++++++++++++++++++++------ 1 files changed, 50 insertions(+), 7 deletions(-) diff -puN arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling arch/i386/kernel/kprobes.c --- linux-2.6.16-rc4-mm2/arch/i386/kernel/kprobes.c~kprobes-i386-pagefault-handling 2006-03-01 19:05:01.000000000 +0530 +++ linux-2.6.16-rc4-mm2-prasanna/arch/i386/kernel/kprobes.c 2006-03-01 19:07:17.000000000 +0530 @@ -35,6 +35,7 @@ #include <asm/cacheflush.h> #include <asm/kdebug.h> #include <asm/desc.h> +#include <asm/uaccess.h> void jprobe_return_end(void); @@ -554,15 +555,57 @@ static inline int kprobe_fault_handler(s struct kprobe *cur = kprobe_running(); struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); - if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) - return 1; - - if (kcb->kprobe_status & KPROBE_HIT_SS) { - resume_execution(cur, regs, kcb); + switch(kcb->kprobe_status) { + case KPROBE_HIT_SS: + case KPROBE_REENTER: + /* + * We are here because the instruction being single + * stepped caused a page fault. We reset the current + * kprobe and the eip points back to the probe address + * and allow the page fault handler to continue as a + * normal page fault. + */ + regs->eip = (unsigned long)cur->addr; regs->eflags |= kcb->kprobe_old_eflags; - - reset_current_kprobe(); + if (kcb->kprobe_status == KPROBE_REENTER) + restore_previous_kprobe(kcb); + else + reset_current_kprobe(); preempt_enable_no_resched(); + break; + case KPROBE_HIT_ACTIVE: + case KPROBE_HIT_SSDONE: + /* + * We increment the nmissed count for accounting, + * we can also use npre/npostfault count for accouting + * these specific fault cases. + */ + kprobes_inc_nmissed_count(cur); + + /* + * We come here because instructions in the pre/post + * handler caused the page_fault, this could happen + * if handler tries to access user space by + * copy_from_user(), get_user() etc. Let the + * user-specified handler try to fix it first. + */ + if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr)) + return 1; + + /* + * In case the user-specified fault handler returned + * zero, try to fix up. + */ + if (fixup_exception(regs)) + return 1; + + /* + * fixup_exception() could not handle it, + * Let do_page_fault() fix it. + */ + break; + default: + break; } return 0; } _ -- Prasanna S Panchamukhi Linux Technology Center India Software Labs, IBM Bangalore Email: prasanna@in.ibm.com Ph: 91-80-51776329 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-03-01 14:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-24 19:17 [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy, Anil S 2006-02-27 9:24 ` Prasanna S Panchamukhi 2006-02-27 9:25 ` [PATCH] Kprobes- robust fault handling for i386 post_handler changes Prasanna S Panchamukhi 2006-02-28 1:02 ` [PATCH] Kprobes- robust fault handling for i386 Keshavamurthy Anil S 2006-02-28 14:37 ` Prasanna S Panchamukhi 2006-02-28 20:25 ` Keshavamurthy Anil S 2006-03-01 14:49 ` Prasanna S Panchamukhi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).