Thread (71 messages) flat view 71 messages, 10 authors, 2016-08-10

[PATCH v15 04/10] arm64: Kprobes with single stepping support

From: catalin.marinas@arm.com (Catalin Marinas)
Date: 2016-07-20 11:16:19
Also in: lkml

On Wed, Jul 20, 2016 at 10:36:08AM +0100, Marc Zyngier wrote:
quoted hunk ↗ jump to hunk
On 08/07/16 17:35, David Long wrote:
quoted
+void __kprobes jprobe_return(void)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	/*
+	 * Jprobe handler return by entering break exception,
+	 * encoded same as kprobe, but with following conditions
+	 * -a magic number in x0 to identify from rest of other kprobes.
+	 * -restore stack addr to original saved pt_regs
+	 */
+	asm volatile ("ldr x0, [%0]\n\t"
+		      "mov sp, x0\n\t"
+		      ".globl jprobe_return_break\n\t"
+		      "jprobe_return_break:\n\t"
+		      "brk %1\n\t"
+		      :
+		      : "r"(&kcb->jprobe_saved_regs.sp),
+		      "I"(BRK64_ESR_KPROBES)
+		      : "memory");
A couple of remarks here:
- the comment seems wrong, as you load the stack pointer in X0, nothing
else, and seem to identify the jprobe by looking at the PC, not X0.
- using explicit registers is really ugly. How about something like this
instead:
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index c89811d..823cf92 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -513,13 +513,12 @@ void __kprobes jprobe_return(void)
 	 * -a magic number in x0 to identify from rest of other kprobes.
 	 * -restore stack addr to original saved pt_regs
 	 */
-	asm volatile ("ldr x0, [%0]\n\t"
-		      "mov sp, x0\n\t"
+	asm volatile ("mov sp, %0\n\t"
 		      ".globl jprobe_return_break\n\t"
 		      "jprobe_return_break:\n\t"
 		      "brk %1\n\t"
 		      :
-		      : "r"(&kcb->jprobe_saved_regs.sp),
+		      : "r" (kcb->jprobe_saved_regs.sp),
 		      "I"(BRK64_ESR_KPROBES)
 		      : "memory");
 }
The comment indeed doesn't make any sense. Is x0 useful at all?
Otherwise, Marc's fixup looks better.
though hijacking SP in the middle of a C function still feels pretty fragile.
It may not be that bad if this function is never supposed to return.
However, I no longer hit jprobe_return() in my tests, it fails earlier
when it hits the function entry breakpoint. One difference from the
default Kprobes tests is that tcp_rcv_established() runs in interrupt
context on the IRQ stack. Maybe setjmp_pre_handler() doesn't set things
up properly.

Also, is setjmp_pre_handler() guaranteed to run in a non-preemptible
context? It uses MIN_STACK_SIZE macro which does a
raw_smp_processor_id().

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help