public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* 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).