[patch] Kprobes ia64 qp fix

[patch] Kprobes ia64 qp fix

[Rusty Lynch]

The following patch is for the 2.6.12-rc5-mm1 + my previous
"Kprobes ia64 cleanup" patch that fixes a bug where a kprobe still 
fires when the instruction is predicated off.  So given the p6=0, 
and we have an instruction like:

(p6) move loc1=0

we should not be triggering the kprobe.  This is handled by carrying over
the qp section of the original instruction into the break instruction.

    --rusty

signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
signed-off-by: Rusty Lynch <Rusty.lynch@intel.com>

 arch/ia64/kernel/kprobes.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
=================================--- linux-2.6.12-rc5.orig/arch/ia64/kernel/kprobes.c
+++ linux-2.6.12-rc5/arch/ia64/kernel/kprobes.c
@@ -115,19 +115,19 @@ int arch_prepare_kprobe(struct kprobe *p
 	case 0:
  		major_opcode = (bundle->quad0.slot0 >> SLOT0_OPCODE_SHIFT);
  		kprobe_inst = bundle->quad0.slot0;
-		bundle->quad0.slot0 = BREAK_INST;
+		bundle->quad0.slot0 = BREAK_INST | (0x3f & kprobe_inst);
 		break;
 	case 1:
  		major_opcode = (bundle->quad1.slot1_p1 >> SLOT1_p1_OPCODE_SHIFT);
  		kprobe_inst = (bundle->quad0.slot1_p0 |
  				(bundle->quad1.slot1_p1 << (64-46)));
-		bundle->quad0.slot1_p0 = BREAK_INST;
+		bundle->quad0.slot1_p0 = BREAK_INST | (0x3f & kprobe_inst);
 		bundle->quad1.slot1_p1 = (BREAK_INST >> (64-46));
 		break;
 	case 2:
  		major_opcode = (bundle->quad1.slot2 >> SLOT2_OPCODE_SHIFT);
  		kprobe_inst = bundle->quad1.slot2;
-		bundle->quad1.slot2 = BREAK_INST;
+		bundle->quad1.slot2 = BREAK_INST | (0x3f & kprobe_inst);
 		break;
 	}
 

Re: [patch] Kprobes ia64 qp fix

[David Mosberger]

>>>>> On Thu, 26 May 2005 10:51:45 -0700, Rusty Lynch <rusty.lynch@intel.com> said:

  Rusty> The following patch is for the 2.6.12-rc5-mm1 + my previous
  Rusty> "Kprobes ia64 cleanup" patch that fixes a bug where a kprobe still 
  Rusty> fires when the instruction is predicated off.  So given the p6=0, 
  Rusty> and we have an instruction like:

  Rusty> (p6) move loc1=0

  Rusty> we should not be triggering the kprobe.  This is handled by
  Rusty> carrying over the qp section of the original instruction into
  Rusty> the break instruction.

What about:

	(p6) cmp.eq.unc p9,p10=rX,rY

would the code handle that right?  Similary, you may want to check for
the correct handling of instructions that cannot be predicated (such
as "cover").

	--david

RE: [patch] Kprobes ia64 qp fix

[Lynch, Rusty]

>>>>>> On Thu, 26 May 2005 10:51:45 -0700, Rusty Lynch
><rusty.lynch@intel.com> said:
>
>  Rusty> The following patch is for the 2.6.12-rc5-mm1 + my previous
>  Rusty> "Kprobes ia64 cleanup" patch that fixes a bug where a kprobe
still
>  Rusty> fires when the instruction is predicated off.  So given the
p6=0,
>  Rusty> and we have an instruction like:
>
>  Rusty> (p6) move loc1=0
>
>  Rusty> we should not be triggering the kprobe.  This is handled by
>  Rusty> carrying over the qp section of the original instruction into
>  Rusty> the break instruction.
>
>What about:
>
>	(p6) cmp.eq.unc p9,p10=rX,rY
>
>would the code handle that right?  Similary, you may want to check for
>the correct handling of instructions that cannot be predicated (such
>as "cover").
>
>	--david

Thanks, I need to look into this one.  Let me update my test to cover
both of these cases and then take another look at our logic.

    --rusty