* [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-25 15:22 ` Will Deacon
2013-10-17 11:17 ` [PATCH RFC 2/6] arm64: Kprobes with single stepping support Sandeepa Prabhu
` (5 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
AArch64 Single Steping and Breakpoint debug exceptions will be
used by multiple debug framworks like kprobes & kgdb.
This patch implements the hooks for those frameworks to register
their own handlers for handling breakpoint and single step events.
Reworked the debug exception handler in entry.S: do_dbg to route
software breakpoint (BRK64) exception to do_debug_exception()
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
---
arch/arm64/include/asm/debug-monitors.h | 21 ++++++++
arch/arm64/kernel/debug-monitors.c | 86 ++++++++++++++++++++++++++++++++-
arch/arm64/kernel/entry.S | 2 +
3 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index a2232d0..6231479 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -62,6 +62,27 @@ struct task_struct;
#define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
+#define DBG_HOOK_HANDLED 0
+#define DBG_HOOK_ERROR 1
+
+struct step_hook {
+ struct list_head node;
+ int (*fn)(struct pt_regs *regs, unsigned int esr);
+};
+
+void register_step_hook(struct step_hook *hook);
+void unregister_step_hook(struct step_hook *hook);
+
+struct break_hook {
+ struct list_head node;
+ u32 esr_val;
+ u32 esr_mask;
+ int (*fn)(struct pt_regs *regs, unsigned int esr);
+};
+
+void register_break_hook(struct break_hook *hook);
+void unregister_break_hook(struct break_hook *hook);
+
u8 debug_monitors_arch(void);
void enable_debug_monitors(enum debug_el el);
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index cbfacf7..e42ad5f 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -188,6 +188,48 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
regs->pstate = spsr;
}
+/* EL1 Single Step Handler hooks */
+static LIST_HEAD(step_hook);
+DEFINE_RWLOCK(step_hook_lock);
+
+void register_step_hook(struct step_hook *hook)
+{
+ write_lock(&step_hook_lock);
+ list_add(&hook->node, &step_hook);
+ write_unlock(&step_hook_lock);
+}
+
+void unregister_step_hook(struct step_hook *hook)
+{
+ write_lock(&step_hook_lock);
+ list_del(&hook->node);
+ write_unlock(&step_hook_lock);
+}
+
+/*
+ * Call registered single step handers
+ * There is no Syndrome info to check for determining the handler.
+ * So we call all the registered handlers, until the right handler is
+ * found which returns zero.
+ */
+static int call_step_hook(struct pt_regs *regs, unsigned int esr)
+{
+ struct step_hook *hook;
+ int retval = DBG_HOOK_ERROR;
+
+ read_lock(&step_hook_lock);
+
+ list_for_each_entry(hook, &step_hook, node) {
+ retval = hook->fn(regs, esr);
+ if (retval == DBG_HOOK_HANDLED)
+ break;
+ }
+
+ read_unlock(&step_hook_lock);
+
+ return retval;
+}
+
static int single_step_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
@@ -215,7 +257,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
*/
user_rewind_single_step(current);
} else {
- /* TODO: route to KGDB */
+ /* call registered single step handlers */
+ if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
+ return 0;
+
pr_warning("Unexpected kernel single-step exception at EL1\n");
/*
* Re-enable stepping since we know that we will be
@@ -227,11 +272,50 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
return 0;
}
+
+static LIST_HEAD(break_hook);
+DEFINE_RWLOCK(break_hook_lock);
+
+void register_break_hook(struct break_hook *hook)
+{
+ write_lock(&break_hook_lock);
+ list_add(&hook->node, &break_hook);
+ write_unlock(&break_hook_lock);
+}
+
+void unregister_break_hook(struct break_hook *hook)
+{
+ write_lock(&break_hook_lock);
+ list_del(&hook->node);
+ write_unlock(&break_hook_lock);
+}
+
+static int call_break_hook(struct pt_regs *regs, unsigned int esr)
+{
+ struct break_hook *hook;
+ int (*fn)(struct pt_regs *regs, unsigned int esr) = NULL;
+
+ read_lock(&break_hook_lock);
+ list_for_each_entry(hook, &break_hook, node)
+ if ((esr & hook->esr_mask) == hook->esr_val)
+ fn = hook->fn;
+ read_unlock(&break_hook_lock);
+
+ return fn ? fn(regs, esr) : DBG_HOOK_ERROR;
+}
+
static int brk_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
siginfo_t info;
+ /* call the registered breakpoint handler */
+ if (call_break_hook(regs, esr) == DBG_HOOK_HANDLED)
+ return 0;
+
+ pr_warn("unexpected brk exception at %lx, esr=0x%x\n",
+ (long)instruction_pointer(regs), esr);
+
if (!user_mode(regs))
return -EFAULT;
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 3881fd1..7fbc510 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -288,6 +288,8 @@ el1_dbg:
/*
* Debug exception handling
*/
+ cmp x24, #ESR_EL1_EC_BRK64 // if BRK64
+ cinc x24, x24, eq // set bit '0'
tbz x24, #0, el1_inv // EL1 only
mrs x0, far_el1
mov x2, sp // struct pt_regs
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks
2013-10-17 11:17 ` [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks Sandeepa Prabhu
@ 2013-10-25 15:22 ` Will Deacon
2013-12-03 14:33 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-10-25 15:22 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
Hi Sandeepa,
This is getting there, thanks for persevering with it. I still have a few
minor comments though.
On Thu, Oct 17, 2013 at 12:17:46PM +0100, Sandeepa Prabhu wrote:
> AArch64 Single Steping and Breakpoint debug exceptions will be
> used by multiple debug framworks like kprobes & kgdb.
>
> This patch implements the hooks for those frameworks to register
> their own handlers for handling breakpoint and single step events.
>
> Reworked the debug exception handler in entry.S: do_dbg to route
> software breakpoint (BRK64) exception to do_debug_exception()
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
> ---
> arch/arm64/include/asm/debug-monitors.h | 21 ++++++++
> arch/arm64/kernel/debug-monitors.c | 86 ++++++++++++++++++++++++++++++++-
> arch/arm64/kernel/entry.S | 2 +
> 3 files changed, 108 insertions(+), 1 deletion(-)
[...]
> @@ -215,7 +257,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
> */
> user_rewind_single_step(current);
> } else {
> - /* TODO: route to KGDB */
> + /* call registered single step handlers */
Don't bother with this comment (it's crystal clear from the code).
> + if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
> + return 0;
> +
> pr_warning("Unexpected kernel single-step exception at EL1\n");
> /*
> * Re-enable stepping since we know that we will be
> @@ -227,11 +272,50 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
> return 0;
> }
>
> +
> +static LIST_HEAD(break_hook);
> +DEFINE_RWLOCK(break_hook_lock);
This guy can be a plain old spinlock. That way, the readers have less
overhead but things still work because we only call a single hook function.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks
2013-10-25 15:22 ` Will Deacon
@ 2013-12-03 14:33 ` Sandeepa Prabhu
2013-12-03 19:44 ` Will Deacon
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-12-03 14:33 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
Hi Will,
Sorry for responding to this after long-time, I missed this review
during Linaro connect travels.
On 25 October 2013 20:52, Will Deacon <will.deacon@arm.com> wrote:
> Hi Sandeepa,
>
> This is getting there, thanks for persevering with it. I still have a few
> minor comments though.
>
> On Thu, Oct 17, 2013 at 12:17:46PM +0100, Sandeepa Prabhu wrote:
>> AArch64 Single Steping and Breakpoint debug exceptions will be
>> used by multiple debug framworks like kprobes & kgdb.
>>
>> This patch implements the hooks for those frameworks to register
>> their own handlers for handling breakpoint and single step events.
>>
>> Reworked the debug exception handler in entry.S: do_dbg to route
>> software breakpoint (BRK64) exception to do_debug_exception()
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
>> ---
>> arch/arm64/include/asm/debug-monitors.h | 21 ++++++++
>> arch/arm64/kernel/debug-monitors.c | 86 ++++++++++++++++++++++++++++++++-
>> arch/arm64/kernel/entry.S | 2 +
>> 3 files changed, 108 insertions(+), 1 deletion(-)
>
> [...]
>
>> @@ -215,7 +257,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
>> */
>> user_rewind_single_step(current);
>> } else {
>> - /* TODO: route to KGDB */
>> + /* call registered single step handlers */
>
> Don't bother with this comment (it's crystal clear from the code).
OK, I will remove this unnecessary print.
>
>> + if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
>> + return 0;
>> +
>> pr_warning("Unexpected kernel single-step exception at EL1\n");
>> /*
>> * Re-enable stepping since we know that we will be
>> @@ -227,11 +272,50 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
>> return 0;
>> }
>>
>> +
>> +static LIST_HEAD(break_hook);
>> +DEFINE_RWLOCK(break_hook_lock);
>
> This guy can be a plain old spinlock. That way, the readers have less
> overhead but things still work because we only call a single hook function.
well, kprobes need to support recursive breakpoints (i.e. breakpoint
handler executing BRK once again)
so I converted this lock to rw_lock. I should put this info in commit
description to be more clearer.
Let me know if you find any issue with re-cursing in breakpoint exception?
Thanks,
Sandeepa
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks
2013-12-03 14:33 ` Sandeepa Prabhu
@ 2013-12-03 19:44 ` Will Deacon
0 siblings, 0 replies; 50+ messages in thread
From: Will Deacon @ 2013-12-03 19:44 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On Tue, Dec 03, 2013 at 02:33:17PM +0000, Sandeepa Prabhu wrote:
> Hi Will,
>
> Sorry for responding to this after long-time, I missed this review
> during Linaro connect travels.
No problem.
> >> @@ -215,7 +257,10 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
> >> */
> >> user_rewind_single_step(current);
> >> } else {
> >> - /* TODO: route to KGDB */
> >> + /* call registered single step handlers */
> >
> > Don't bother with this comment (it's crystal clear from the code).
> OK, I will remove this unnecessary print.
Thanks.
> >> +static LIST_HEAD(break_hook);
> >> +DEFINE_RWLOCK(break_hook_lock);
> >
> > This guy can be a plain old spinlock. That way, the readers have less
> > overhead but things still work because we only call a single hook function.
> well, kprobes need to support recursive breakpoints (i.e. breakpoint
> handler executing BRK once again)
> so I converted this lock to rw_lock. I should put this info in commit
> description to be more clearer.
Actually, this is one place where a comment in the code *would* be useful!
> Let me know if you find any issue with re-cursing in breakpoint exception?
Sounds ok to me. With those changes:
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 16:56 ` Will Deacon
2013-10-17 11:17 ` [PATCH RFC 3/6] arm64: Kprobes instruction simulation support Sandeepa Prabhu
` (4 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
Add support for basic kernel probes(kprobes), jump probes (jprobes)
for ARM64.
Kprobes will utilize software breakpoint and single step debug
exceptions supported on ARM v8.
software breakpoint is placed at the probe address to trap the
kernel execution into kprobe handler.
ARM v8 support single stepping to be enabled while exception return
(ERET) with next PC in exception return address (ELR_EL1).
kprobe handler prepares a executable memory slot for out-of-line
execution with the copy of the original instruction under probe, and
enable single stepping from the instruction slot. With this scheme,
the instruction is executed with the exact same register context
'except PC' that points to instruction slot.
Debug mask(PSTATE.D) is enabled while calling user pre & post handlers
since it can hit breakpoint again(like kprobe placed on printk, with
user handler invoking printk again). This allow kprobe re-entry and
any further re-entry is prevented by not calling handlers (counted as
missed kprobe)
Single stepping from slot has drawback on PC-relative accesses
like branching and symbolic literals access as offset from new PC
may not be ensured to fit in immediate value of opcode,
(usually +/-1MB range). So these instructions needs simulation, so
are not allowed to place probe on those instructions.
Instructions generating exceptions or cpu mode change are rejected,
and not allowed to insert probe for such instructions.
Instructions using Exclusive Monitor are rejected right now.
System instructions are mostly enabled for stepping, except MSR
immediate that update "daif" flags in PSTATE, which are not safe
for probing(rejected)
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kprobes.h | 59 +++++
arch/arm64/include/asm/probes.h | 50 ++++
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/kprobes-arm64.c | 211 +++++++++++++++
arch/arm64/kernel/kprobes-arm64.h | 28 ++
arch/arm64/kernel/kprobes.c | 538 ++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/kprobes.h | 30 +++
arch/arm64/kernel/probes-decode.h | 110 ++++++++
arch/arm64/kernel/vmlinux.lds.S | 1 +
11 files changed, 1030 insertions(+)
create mode 100644 arch/arm64/include/asm/kprobes.h
create mode 100644 arch/arm64/include/asm/probes.h
create mode 100644 arch/arm64/kernel/kprobes-arm64.c
create mode 100644 arch/arm64/kernel/kprobes-arm64.h
create mode 100644 arch/arm64/kernel/kprobes.c
create mode 100644 arch/arm64/kernel/kprobes.h
create mode 100644 arch/arm64/kernel/probes-decode.h
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index da388e4..2e89059 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -27,6 +27,7 @@ config ARM64
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_MEMBLOCK
select HAVE_PERF_EVENTS
+ select HAVE_KPROBES if !XIP_KERNEL
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 0000000..9b491d0
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,59 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include <linux/types.h>
+#include <linux/ptrace.h>
+#include <linux/percpu.h>
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE 2
+#define MAX_STACK_SIZE 128
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size 0
+
+#include <asm/probes.h>
+
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+#define KPROBES_STEP_NONE 0x0
+#define KPROBES_STEP_PENDING 0x1
+ unsigned long ss_status;
+ unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ struct prev_kprobe prev_kprobe;
+ struct kprobe_step_ctx ss_ctx;
+ struct pt_regs jprobe_saved_regs;
+ char jprobes_stack[MAX_STACK_SIZE];
+};
+
+void arch_remove_kprobe(struct kprobe *);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
+int kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data);
+
+#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
new file mode 100644
index 0000000..c9c7734
--- /dev/null
+++ b/arch/arm64/include/asm/probes.h
@@ -0,0 +1,50 @@
+/*
+ * arch/arm64/include/asm/probes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#ifndef _ARM_PROBES_H
+#define _ARM_PROBES_H
+
+struct kprobe;
+struct arch_specific_insn;
+
+typedef u32 kprobe_opcode_t;
+typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
+typedef unsigned long
+(kprobes_condition_check_t)(struct kprobe *p, struct pt_regs *);
+typedef void
+(kprobes_prepare_t)(struct kprobe *, struct arch_specific_insn *);
+typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
+
+typedef enum {
+ NO_RESTORE,
+ RESTORE_PC,
+} pc_restore_t;
+
+struct kprobe_pc_restore {
+ pc_restore_t type;
+ unsigned long addr;
+};
+
+/* architecture specific copy of original instruction */
+struct arch_specific_insn {
+ kprobe_opcode_t *insn;
+ kprobes_pstate_check_t *pstate_cc;
+ kprobes_condition_check_t *check_condn;
+ kprobes_prepare_t *prepare;
+ kprobes_handler_t *handler;
+ /* restore address after step xol */
+ struct kprobe_pc_restore restore;
+};
+
+#endif
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 0dacbbf..89f1727 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -164,6 +164,7 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
}
#define instruction_pointer(regs) (regs)->pc
+#define stack_pointer(regs) ((regs)->sp)
#ifdef CONFIG_SMP
extern unsigned long profile_pc(struct pt_regs *regs);
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index b7db65e..12ef8d2 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -19,6 +19,7 @@ arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
+arm64-obj-$(CONFIG_KPROBES) += kprobes.o kprobes-arm64.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
new file mode 100644
index 0000000..30d1c14
--- /dev/null
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -0,0 +1,211 @@
+/*
+ * arch/arm64/kernel/kprobes-arm64.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <asm/kprobes.h>
+
+#include "probes-decode.h"
+#include "kprobes-arm64.h"
+
+/* AArch64 instruction decode table for kprobes:
+ * The instruction will fall into one of the 3 groups:
+ * 1. Single stepped out-of-the-line slot.
+ * -Most instructions fall in this group, those does not
+ * depend on PC address.
+ *
+ * 2. Should be simulated because of PC-relative/literal access.
+ * -All branching and PC-relative insrtcutions are simulated
+ * in C code, making use of saved pt_regs
+ * Catch: SIMD/NEON register context are not saved while
+ * entering debug exception, so are rejected for now.
+ *
+ * 3. Cannot be probed(not safe) so are rejected.
+ * - Exception generation and exception return instructions
+ * - Exclusive monitor(LDREX/STREX family)
+ *
+ */
+static const struct aarch64_decode_item aarch64_decode_table[] = {
+ /*
+ * Data processing - PC relative(literal) addressing:
+ * Encoding: xxx1 0000 xxxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_REJECT(0x10000000, 0x1F000000),
+
+ /*
+ * Data processing - Add/Substract Immediate:
+ * Encoding: xxx1 0001 xxxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_SINGLESTEP(0x11000000, 0x1F000000),
+
+ /*
+ * Data processing
+ * Encoding:
+ * xxx1 0010 0xxx xxxx xxxx xxxx xxxx xxxx (Logical)
+ * xxx1 0010 1xxx xxxx xxxx xxxx xxxx xxxx (Move wide)
+ * xxx1 0011 0xxx xxxx xxxx xxxx xxxx xxxx (Bitfield)
+ * xxx1 0011 1xxx xxxx xxxx xxxx xxxx xxxx (Extract)
+ */
+ DECODE_SINGLESTEP(0x12000000, 0x1E000000),
+
+ /*
+ * Data processing - SIMD/FP/AdvSIMD/Crypto-AES/SHA
+ * Encoding: xxx0 111x xxxx xxxx xxxx xxxx xxxx xxxx
+ * Encoding: xxx1 111x xxxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_SINGLESTEP(0x0E000000, 0x0E000000),
+
+ /*
+ * Data processing - Register
+ * Encoding: xxxx 101x xxxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_SINGLESTEP(0x0A000000, 0x0E000000),
+
+ /* Branching Instructions
+ *
+ * Encoding:
+ * x001 01xx xxxx xxxx xxxx xxxx xxxx xxxx (uncondtional Branch)
+ * x011 010x xxxx xxxx xxxx xxxx xxxx xxxx (compare & branch)
+ * x011 011x xxxx xxxx xxxx xxxx xxxx xxxx (Test & Branch)
+ * 0101 010x xxxx xxxx xxxx xxxx xxxx xxxx (Conditional, immediate)
+ * 1101 011x xxxx xxxx xxxx xxxx xxxx xxxx (Unconditional,register)
+ */
+ DECODE_REJECT(0x14000000, 0x7C000000),
+ DECODE_REJECT(0x14000000, 0x7C000000),
+ DECODE_REJECT(0x34000000, 0x7E000000),
+ DECODE_REJECT(0x36000000, 0x7E000000),
+ DECODE_REJECT(0x54000000, 0xFE000000),
+ DECODE_REJECT(0xD6000000, 0xFE000000),
+
+ /* System insn:
+ * Encoding: 1101 0101 00xx xxxx xxxx xxxx xxxx xxxx
+ *
+ * Note: MSR immediate (update PSTATE daif) is not safe handling
+ * within kprobes, rejected.
+ *
+ * Don't re-arrange these decode table entries.
+ */
+ DECODE_REJECT(0xD500401F, 0xFFF8F01F),
+ DECODE_SINGLESTEP(0xD5000000, 0xFFC00000),
+
+ /* Exception Generation:
+ * Encoding: 1101 0100 xxxx xxxx xxxx xxxx xxxx xxxx
+ * Instructions: SVC, HVC, SMC, BRK, HLT, DCPS1, DCPS2, DCPS3
+ */
+ DECODE_REJECT(0xD4000000, 0xFF000000),
+
+ /*
+ * Load/Store - Exclusive monitor
+ * Encoding: xx00 1000 xxxx xxxx xxxx xxxx xxxx xxxx
+ *
+ * Reject exlusive monitor'ed instructions
+ */
+ DECODE_REJECT(0x08000000, 0x3F000000),
+
+ /*
+ * Load/Store - PC relative(literal):
+ * Encoding: xx01 1x00 xxxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_REJECT(0x18000000, 0x3B000000),
+
+ /*
+ * Load/Store - Register Pair
+ * Encoding:
+ * xx10 1x00 0xxx xxxx xxxx xxxx xxxx xxxx
+ * xx10 1x00 1xxx xxxx xxxx xxxx xxxx xxxx
+ * xx10 1x01 0xxx xxxx xxxx xxxx xxxx xxxx
+ * xx10 1x01 1xxx xxxx xxxx xxxx xxxx xxxx
+ */
+ DECODE_SINGLESTEP(0x28000000, 0x3A000000),
+
+ /*
+ * Load/Store - Register
+ * Encoding:
+ * xx11 1x00 xx0x xxxx xxxx 00xx xxxx xxxx (unscaled imm)
+ * xx11 1x00 xx0x xxxx xxxx 01xx xxxx xxxx (imm post-indexed)
+ * xx11 1x00 xx0x xxxx xxxx 10xx xxxx xxxx (unpriviledged)
+ * xx11 1x00 xx0x xxxx xxxx 11xx xxxx xxxx (imm pre-indexed)
+ *
+ * xx11 1x00 xx10 xxxx xxxx xx10 xxxx xxxx (register offset)
+ *
+ * xx11 1x01 xxxx xxxx xxxx xxxx xxxx xxxx (unsigned imm)
+ */
+ DECODE_SINGLESTEP(0x38000000, 0x3B200000),
+ DECODE_SINGLESTEP(0x38200200, 0x38300300),
+ DECODE_SINGLESTEP(0x39000000, 0x3B000000),
+
+ /*
+ * Load/Store - AdvSIMD
+ * Encoding:
+ * 0x00 1100 0x00 0000 xxxx xxxx xxxx xxxx (Multiple-structure)
+ * 0x00 1100 1x0x xxxx xxxx xxxx xxxx xxxx (Multi-struct post-indexed)
+ * 0x00 1101 0xx0 0000 xxxx xxxx xxxx xxxx (Single-structure))
+ * 0x00 1101 1xxx xxxx xxxx xxxx xxxx xxxx (Single-struct post-index)
+ */
+ DECODE_SINGLESTEP(0x0C000000, 0xBFBF0000),
+ DECODE_SINGLESTEP(0x0C800000, 0xBFA00000),
+ DECODE_SINGLESTEP(0x0D000000, 0xBF9F0000),
+ DECODE_SINGLESTEP(0x0D800000, 0xBF800000),
+
+ /* Unallocated: xxx0 0xxx xxxx xxxx xxxx xxxx xxxx xxxx */
+ DECODE_REJECT(0x00000000, 0x18000000),
+ DECODE_END,
+};
+
+static int __kprobes
+kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
+ const struct aarch64_decode_item *tbl)
+{
+ unsigned int entry, ret = INSN_REJECTED;
+
+ for (entry = 0; !decode_table_end(tbl[entry]); entry++) {
+ if (decode_table_hit(tbl[entry], insn))
+ break;
+ }
+
+ switch (decode_get_type(tbl[entry])) {
+ case DECODE_TYPE_END:
+ case DECODE_TYPE_REJECT:
+ default:
+ ret = INSN_REJECTED;
+ break;
+
+ case DECODE_TYPE_SINGLESTEP:
+ ret = INSN_GOOD;
+ break;
+
+ case DECODE_TYPE_SIMULATE:
+ ret = INSN_REJECTED;
+ break;
+
+ case DECODE_TYPE_TABLE:
+ /* recurse with next level decode table */
+ ret = kprobe_decode_insn(insn, asi,
+ decode_sub_table(tbl[entry]));
+ };
+ return ret;
+}
+
+/* Return:
+ * INSN_REJECTED If instruction is one not allowed to kprobe,
+ * INSN_GOOD If instruction is supported and uses instruction slot,
+ * INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
+ */
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
+{
+ return kprobe_decode_insn(insn, asi, aarch64_decode_table);
+}
diff --git a/arch/arm64/kernel/kprobes-arm64.h b/arch/arm64/kernel/kprobes-arm64.h
new file mode 100644
index 0000000..87e7891
--- /dev/null
+++ b/arch/arm64/kernel/kprobes-arm64.h
@@ -0,0 +1,28 @@
+/*
+ * arch/arm64/kernel/kprobes-arm64.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_ARM64_H
+#define _ARM_KERNEL_KPROBES_ARM64_H
+
+enum kprobe_insn {
+ INSN_REJECTED,
+ INSN_GOOD_NO_SLOT,
+ INSN_GOOD,
+};
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi);
+
+#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
new file mode 100644
index 0000000..def10b6
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.c
@@ -0,0 +1,538 @@
+/*
+ * arch/arm64/kernel/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/stop_machine.h>
+#include <linux/stringify.h>
+#include <asm/traps.h>
+#include <asm/cacheflush.h>
+#include <asm/debug-monitors.h>
+#include <asm/system_misc.h>
+#include <asm/insn.h>
+
+#include "kprobes.h"
+#include "kprobes-arm64.h"
+
+#define MIN_STACK_SIZE(addr) min((unsigned long)MAX_STACK_SIZE, \
+ (unsigned long)current_thread_info() + THREAD_START_SP - (addr))
+
+DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
+DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+
+static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+{
+ int i;
+ /* prepare insn slot */
+ p->ainsn.insn[0] = p->opcode;
+ /* NOP for superscalar uArch decode */
+ for (i = 1; i < MAX_INSN_SIZE; i++)
+ p->ainsn.insn[i] = ARCH64_NOP_OPCODE;
+
+ flush_icache_range((uintptr_t) (p->ainsn.insn),
+ (uintptr_t) (p->ainsn.insn) + MAX_INSN_SIZE);
+}
+
+int __kprobes arch_prepare_kprobe(struct kprobe *p)
+{
+ kprobe_opcode_t insn;
+ unsigned long probe_addr = (unsigned long)p->addr;
+
+ /* copy instruction */
+ insn = *p->addr;
+ p->opcode = insn;
+
+ if (in_exception_text(probe_addr))
+ return -EINVAL;
+
+ /* decode instruction */
+ switch (arm_kprobe_decode_insn(insn, &p->ainsn)) {
+ case INSN_REJECTED: /* insn not supported */
+ return -EINVAL;
+ break;
+
+ case INSN_GOOD_NO_SLOT: /* insn need simulation */
+ return -EINVAL;
+ break;
+
+ case INSN_GOOD: /* instruction uses slot */
+ p->ainsn.insn = get_insn_slot();
+ if (!p->ainsn.insn)
+ return -ENOMEM;
+ break;
+ };
+
+ /* prepare the instruction */
+ arch_prepare_ss_slot(p);
+
+ return 0;
+}
+
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+ void *addrs[1];
+ u32 insns[1];
+
+ addrs[0] = (void *)addr;
+ insns[0] = (u32)opcode;
+
+ return aarch64_insn_patch_text_sync(addrs, insns, 1);
+}
+
+/* arm kprobe: install breakpoint in text */
+void __kprobes arch_arm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, BRK64_OPCODE_KPROBES);
+}
+
+/* disarm kprobe: remove breakpoint from text */
+void __kprobes arch_disarm_kprobe(struct kprobe *p)
+{
+ patch_text(p->addr, p->opcode);
+}
+
+void __kprobes arch_remove_kprobe(struct kprobe *p)
+{
+ if (p->ainsn.insn) {
+ free_insn_slot(p->ainsn.insn, 0);
+ p->ainsn.insn = NULL;
+ }
+}
+
+static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ kcb->prev_kprobe.kp = kprobe_running();
+ kcb->prev_kprobe.status = kcb->kprobe_status;
+}
+
+static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+ __get_cpu_var(current_kprobe) = kcb->prev_kprobe.kp;
+ kcb->kprobe_status = kcb->prev_kprobe.status;
+}
+
+static void __kprobes set_current_kprobe(struct kprobe *p)
+{
+ __get_cpu_var(current_kprobe) = p;
+}
+
+static void __kprobes
+set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ kcb->ss_ctx.ss_status = KPROBES_STEP_PENDING;
+ kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
+}
+
+static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
+{
+ kcb->ss_ctx.ss_status = KPROBES_STEP_NONE;
+ kcb->ss_ctx.match_addr = 0;
+}
+
+static void __kprobes
+nop_singlestep_skip(struct kprobe *p, struct pt_regs *regs)
+{
+ /* set return addr to next pc to continue */
+ instruction_pointer(regs) += sizeof(kprobe_opcode_t);
+ return;
+}
+
+/* Mask/Unmask PSTATE.D flag
+ *
+ * Unmasking D-flag enables recursing into another debug
+ * exception (breakpoint or single step).
+ *
+ * Upon every exception entry, D-flag is disabled by the
+ * hardware. We shall unmask this flag only after safely
+ * saved the previous context and kprobes state machines.
+ *
+ * kprobes can generate recursing in breakpoint (followed
+ * by single stepping) within user-provided handlers only.
+ *
+ * All other places, keep the D-flag masked.
+ */
+static void mask_pstate_debug_flag(u32 mask)
+{
+ if (mask)
+ asm volatile("msr daifset, #9\n\t");
+ else
+ asm volatile("msr daifclr, #9\n\t");
+}
+
+static void __kprobes setup_singlestep(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb, int reenter)
+{
+ unsigned long slot;
+
+ if (reenter) {
+ save_previous_kprobe(kcb);
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_REENTER;
+ } else {
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ }
+
+ if (p->ainsn.insn) {
+ /* prepare for single stepping */
+ slot = (unsigned long)p->ainsn.insn;
+
+ /*
+ * Needs restoring of return address after stepping xol.
+ */
+ p->ainsn.restore.addr = instruction_pointer(regs) +
+ sizeof(kprobe_opcode_t);
+ p->ainsn.restore.type = RESTORE_PC;
+
+ set_ss_context(kcb, slot); /* mark pending ss */
+ kernel_enable_single_step(regs);
+ instruction_pointer(regs) = slot;
+ } else {
+ BUG();
+ }
+}
+
+static int __kprobes reenter_kprobe(struct kprobe *p,
+ struct pt_regs *regs,
+ struct kprobe_ctlblk *kcb)
+{
+ switch (kcb->kprobe_status) {
+ case KPROBE_HIT_SSDONE:
+ case KPROBE_HIT_ACTIVE:
+ if (!p->ainsn.check_condn || p->ainsn.check_condn(p, regs)) {
+ kprobes_inc_nmissed_count(p);
+ setup_singlestep(p, regs, kcb, 1);
+ } else {
+ /* condition failed, it's NOP so skip stepping */
+ nop_singlestep_skip(p, regs);
+ }
+ break;
+ case KPROBE_HIT_SS:
+ pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
+ dump_kprobe(p);
+ BUG();
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+
+ return 1;
+}
+
+static int __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
+{
+ struct kprobe *cur = kprobe_running();
+
+ if (!cur)
+ return 0;
+
+ /* return addr restore if non-branching insn */
+ if (cur->ainsn.restore.type == RESTORE_PC) {
+ instruction_pointer(regs) = cur->ainsn.restore.addr;
+ cur->ainsn.restore.addr = 0;
+ cur->ainsn.restore.type = NO_RESTORE;
+ }
+
+ /* restore back original saved kprobe variables and continue */
+ if (kcb->kprobe_status == KPROBE_REENTER) {
+ restore_previous_kprobe(kcb);
+ goto out;
+ } else { /* call post handler */
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ if (cur->post_handler) {
+ /* post_handler can hit breakpoint and single step
+ * again, so we enable D-flag for recursive exception.
+ */
+ mask_pstate_debug_flag(0);
+ cur->post_handler(cur, regs, 0);
+ mask_pstate_debug_flag(1);
+ }
+ }
+ reset_current_kprobe();
+out:
+
+ return 1;
+}
+
+int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
+{
+ struct kprobe *cur = kprobe_running();
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ 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 ip points back to the probe address
+ * and allow the page fault handler to continue as a
+ * normal page fault.
+ */
+ instruction_pointer(regs) = (unsigned long)cur->addr;
+ if (kcb->kprobe_status == KPROBE_REENTER)
+ restore_previous_kprobe(kcb);
+ else
+ reset_current_kprobe();
+
+ break;
+ case KPROBE_HIT_ACTIVE:
+ case KPROBE_HIT_SSDONE:
+ /*
+ * We increment the nmissed count for accounting,
+ * we can also use npre/npostfault count for accounting
+ * 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, fsr))
+ return 1;
+
+ /*
+ * In case the user-specified fault handler returned
+ * zero, try to fix up.
+ */
+ if (fixup_exception(regs))
+ return 1;
+
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
+ unsigned long val, void *data)
+{
+ return NOTIFY_DONE;
+}
+
+void __kprobes kprobe_handler(struct pt_regs *regs)
+{
+ struct kprobe *p, *cur;
+ struct kprobe_ctlblk *kcb;
+ unsigned long addr = instruction_pointer(regs);
+
+ kcb = get_kprobe_ctlblk();
+ cur = kprobe_running();
+
+ p = get_kprobe((kprobe_opcode_t *) addr);
+
+ if (p) {
+ if (cur) {
+ if (reenter_kprobe(p, regs, kcb))
+ return;
+ } else if (!p->ainsn.check_condn ||
+ p->ainsn.check_condn(p, regs)) {
+ /* Probe hit and conditional execution check ok. */
+ set_current_kprobe(p);
+ kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+
+ /*
+ * If we have no pre-handler or it returned 0, we
+ * continue with normal processing. If we have a
+ * pre-handler and it returned non-zero, it prepped
+ * for calling the break_handler below on re-entry,
+ * so get out doing nothing more here.
+ *
+ * pre_handler can hit a breakpoint and can step thru
+ * before return, keep PSTATE D-flag enabled until
+ * pre_handler return back.
+ */
+ mask_pstate_debug_flag(0);
+ if (!p->pre_handler || !p->pre_handler(p, regs)) {
+ mask_pstate_debug_flag(1);
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ setup_singlestep(p, regs, kcb, 0);
+ return;
+ }
+ mask_pstate_debug_flag(1);
+ } else {
+ /*
+ * Breakpoint hit but conditional check failed,
+ * so just skip handling since it is NOP.
+ */
+ nop_singlestep_skip(p, regs);
+ return;
+ }
+ } else if (*(kprobe_opcode_t *) addr != BRK64_OPCODE_KPROBES) {
+ /*
+ * The breakpoint instruction was removed right
+ * after we hit it. Another cpu has removed
+ * either a probepoint or a debugger breakpoint
+ * at this address. In either case, no further
+ * handling of this interrupt is appropriate.
+ * Return back to original instruction, and continue.
+ */
+ preempt_enable_no_resched();
+ return;
+ } else if (cur) {
+ /* We probably hit a jprobe. Call its break handler. */
+ if (cur->break_handler && cur->break_handler(cur, regs)) {
+ kcb->kprobe_status = KPROBE_HIT_SS;
+ setup_singlestep(cur, regs, kcb, 0);
+ return;
+ }
+ } else {
+ /* breakpoint is removed, now in a race
+ * Return back to original instruction & continue.
+ */
+ preempt_enable_no_resched();
+ }
+ return;
+}
+
+static int __kprobes
+kprobe_ss_hit(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+ if ((kcb->ss_ctx.ss_status == KPROBES_STEP_PENDING)
+ && (kcb->ss_ctx.match_addr == addr)) {
+ clear_ss_context(kcb); /* clear pending ss */
+ return DBG_HOOK_HANDLED;
+ } else {
+ /* not ours, kprobes should ignore it */
+ return DBG_HOOK_ERROR;
+ }
+}
+
+static int __kprobes
+kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ unsigned long flags;
+ int retval;
+
+ /* check, and return error if this is not our step */
+ retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
+
+ if (retval == DBG_HOOK_HANDLED) {
+ /* single step complete, call post handlers */
+ local_irq_save(flags);
+ kernel_disable_single_step();
+ post_kprobe_handler(kcb, regs);
+ local_irq_restore(flags);
+ }
+ return retval;
+}
+
+static int __kprobes
+kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
+{
+ unsigned long flags;
+ local_irq_save(flags);
+ kprobe_handler(regs);
+ local_irq_restore(flags);
+
+ return DBG_HOOK_HANDLED;
+}
+
+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_ptr = stack_pointer(regs);
+
+ kcb->jprobe_saved_regs = *regs;
+ memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+ MIN_STACK_SIZE(stack_ptr));
+
+ instruction_pointer(regs) = (long)jp->entry;
+
+ preempt_disable();
+ return 1;
+}
+
+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"
+ "ldr x0, =" __stringify(JPROBES_MAGIC_NUM) "\n\t"
+ "BRK %1\n\t"
+ "NOP\n\t"
+ :
+ : "r"(&kcb->jprobe_saved_regs.sp),
+ "I"(BRK64_ESR_KPROBES)
+ : "memory");
+}
+
+int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+ long stack_addr = kcb->jprobe_saved_regs.sp;
+ long orig_sp = stack_pointer(regs);
+ struct jprobe *jp = container_of(p, struct jprobe, kp);
+
+ if (regs->regs[0] == JPROBES_MAGIC_NUM) {
+ if (orig_sp != stack_addr) {
+ struct pt_regs *saved_regs =
+ (struct pt_regs *)kcb->jprobe_saved_regs.sp;
+ pr_err("current sp %lx does not match saved sp %lx\n",
+ orig_sp, stack_addr);
+ pr_err("Saved registers for jprobe %p\n", jp);
+ show_regs(saved_regs);
+ pr_err("Current registers\n");
+ show_regs(regs);
+ BUG();
+ }
+ *regs = kcb->jprobe_saved_regs;
+ memcpy((void *)stack_addr, kcb->jprobes_stack,
+ MIN_STACK_SIZE(stack_addr));
+ preempt_enable_no_resched();
+ return 1;
+ }
+ return 0;
+}
+
+/* Break Handler hook */
+static struct break_hook kprobes_break_hook = {
+ .esr_mask = BRK64_ESR_MASK,
+ .esr_val = BRK64_ESR_KPROBES,
+ .fn = kprobe_breakpoint_handler,
+};
+
+/* Single Step handler hook */
+static struct step_hook kprobes_step_hook = {
+ .fn = kprobe_single_step_handler,
+};
+
+int __init arch_init_kprobes()
+{
+ register_break_hook(&kprobes_break_hook);
+ register_step_hook(&kprobes_step_hook);
+
+ return 0;
+}
diff --git a/arch/arm64/kernel/kprobes.h b/arch/arm64/kernel/kprobes.h
new file mode 100644
index 0000000..93c54b4
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.h
@@ -0,0 +1,30 @@
+/*
+ * arch/arm64/kernel/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_H
+#define _ARM_KERNEL_KPROBES_H
+
+/* BRK opcodes with ESR encoding */
+#define BRK64_ESR_MASK 0xFFFF
+#define BRK64_ESR_KPROBES 0x0004
+#define BRK64_OPCODE_KPROBES 0xD4200080 /* "brk 0x4" */
+#define ARCH64_NOP_OPCODE 0xD503201F
+
+#define JPROBES_MAGIC_NUM 0xa5a5a5a5a5a5a5a5
+
+/* Move this out to appropriate header file */
+int fixup_exception(struct pt_regs *regs);
+
+#endif /* _ARM_KERNEL_KPROBES_H */
diff --git a/arch/arm64/kernel/probes-decode.h b/arch/arm64/kernel/probes-decode.h
new file mode 100644
index 0000000..3650ab3
--- /dev/null
+++ b/arch/arm64/kernel/probes-decode.h
@@ -0,0 +1,110 @@
+/*
+ * arch/arm64/kernel/probes-decode.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_PROBES_DECODE_H
+#define _ARM_KERNEL_PROBES_DECODE_H
+
+/*
+ * The following definitions and macros are used to build instruction
+ * decoding tables.
+ */
+enum decode_type {
+ DECODE_TYPE_END,
+ DECODE_TYPE_SINGLESTEP,
+ DECODE_TYPE_SIMULATE,
+ DECODE_TYPE_TABLE,
+ DECODE_TYPE_REJECT,
+};
+
+struct aarch64_decode_item;
+
+struct aarch64_decode_header {
+ enum decode_type type;
+ u32 mask;
+ u32 val;
+};
+
+struct aarch64_decode_actions {
+ kprobes_prepare_t *prepare;
+ kprobes_handler_t *handler;
+};
+
+struct aarch64_decode_table {
+ const struct aarch64_decode_item *tbl;
+};
+
+union aarch64_decode_handler {
+ struct aarch64_decode_actions actions;
+ struct aarch64_decode_table table;
+};
+
+struct aarch64_decode_item {
+ struct aarch64_decode_header header;
+ union aarch64_decode_handler decode;
+};
+
+#define decode_get_type(_entry) ((_entry).header.type)
+
+#define decode_table_end(_entry) \
+ ((_entry).header.type == DECODE_TYPE_END)
+
+#define decode_table_hit(_entry, insn) \
+ ((insn & (_entry).header.mask) == (_entry).header.val)
+
+#define decode_prepare_fn(_entry) ((_entry).decode.actions.prepare)
+#define decode_handler_fn(_entry) ((_entry).decode.actions.handler)
+#define decode_sub_table(_entry) ((_entry).decode.table.tbl)
+
+#define DECODE_ADD_HEADER(_type, _val, _mask) \
+ .header = { \
+ .type = _type, \
+ .mask = _mask, \
+ .val = _val, \
+ },
+
+#define DECODE_ADD_ACTION(_prepare, _handler) \
+ .decode = { \
+ .actions = { \
+ .prepare = _prepare, \
+ .handler = _handler, \
+ } \
+ },
+
+#define DECODE_ADD_TABLE(_table) \
+ .decode = { \
+ .table = {.tbl = _table} \
+ },
+
+#define DECODE_REJECT(_v, _m) \
+ { DECODE_ADD_HEADER(DECODE_TYPE_REJECT, _v, _m) }
+
+#define DECODE_SINGLESTEP(_v, _m) \
+ { DECODE_ADD_HEADER(DECODE_TYPE_SINGLESTEP, _v, _m) }
+
+#define DECODE_SIMULATE(_v, _m, _p, _h) \
+ { DECODE_ADD_HEADER(DECODE_TYPE_SIMULATE, _v, _m) \
+ DECODE_ADD_ACTION(_p, _h) }
+
+#define DECODE_TABLE(_v, _m, _table) \
+ { DECODE_ADD_HEADER(DECODE_TYPE_TABLE, _v, _m) \
+ DECODE_ADD_TABLE(_table) }
+
+#define DECODE_LITERAL(_v, _m, _p, _h) DECODE_SIMULATE(_v, _m, _p, _h)
+#define DECODE_BRANCH(_v, _m, _p, _h) DECODE_SIMULATE(_v, _m, _p, _h)
+
+/* should be the last element in decode structure */
+#define DECODE_END { .header = {.type = DECODE_TYPE_END, } }
+
+#endif /* _ARM_KERNEL_PROBES_DECODE_H */
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index f8ab9d8..40951b1 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -62,6 +62,7 @@ SECTIONS
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
+ KPROBES_TEXT
HYPERVISOR_TEXT
*(.fixup)
*(.gnu.warning)
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-10-17 11:17 ` [PATCH RFC 2/6] arm64: Kprobes with single stepping support Sandeepa Prabhu
@ 2013-11-08 16:56 ` Will Deacon
2013-11-09 9:10 ` Masami Hiramatsu
2013-11-11 5:35 ` Sandeepa Prabhu
0 siblings, 2 replies; 50+ messages in thread
From: Will Deacon @ 2013-11-08 16:56 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
Hi Sandeepa,
On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
> Add support for basic kernel probes(kprobes), jump probes (jprobes)
> for ARM64.
I think this series will conflict quite heavily with the jump_label series,
since they both introduce some common instruction manipulation code. On the
debug side, there will also be conflicts with the kgdb series, so it might
make sense for us to merge those two first, then you can rebase on a stable
branch from us.
[...]
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> new file mode 100644
> index 0000000..9b491d0
> --- /dev/null
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -0,0 +1,59 @@
> +/*
> + * arch/arm64/include/asm/kprobes.h
> + *
> + * Copyright (C) 2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _ARM_KPROBES_H
> +#define _ARM_KPROBES_H
> +
> +#include <linux/types.h>
> +#include <linux/ptrace.h>
> +#include <linux/percpu.h>
> +
> +#define __ARCH_WANT_KPROBES_INSN_SLOT
> +#define MAX_INSN_SIZE 2
Why is this 2?
> +#define MAX_STACK_SIZE 128
> +
> +#define flush_insn_slot(p) do { } while (0)
> +#define kretprobe_blacklist_size 0
> +
> +#include <asm/probes.h>
> +
> +struct prev_kprobe {
> + struct kprobe *kp;
> + unsigned int status;
> +};
> +
> +/* Single step context for kprobe */
> +struct kprobe_step_ctx {
> +#define KPROBES_STEP_NONE 0x0
> +#define KPROBES_STEP_PENDING 0x1
Maybe use an enum to stay consistent with what you did for pc_restore_t?
> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
> new file mode 100644
> index 0000000..30d1c14
> --- /dev/null
> +++ b/arch/arm64/kernel/kprobes-arm64.c
> @@ -0,0 +1,211 @@
> +/*
> + * arch/arm64/kernel/kprobes-arm64.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +#include <asm/kprobes.h>
> +
> +#include "probes-decode.h"
> +#include "kprobes-arm64.h"
> +
> +/* AArch64 instruction decode table for kprobes:
> + * The instruction will fall into one of the 3 groups:
> + * 1. Single stepped out-of-the-line slot.
> + * -Most instructions fall in this group, those does not
> + * depend on PC address.
> + *
> + * 2. Should be simulated because of PC-relative/literal access.
> + * -All branching and PC-relative insrtcutions are simulated
> + * in C code, making use of saved pt_regs
> + * Catch: SIMD/NEON register context are not saved while
> + * entering debug exception, so are rejected for now.
> + *
> + * 3. Cannot be probed(not safe) so are rejected.
> + * - Exception generation and exception return instructions
> + * - Exclusive monitor(LDREX/STREX family)
> + *
> + */
> +static const struct aarch64_decode_item aarch64_decode_table[] = {
> + /*
> + * Data processing - PC relative(literal) addressing:
> + * Encoding: xxx1 0000 xxxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_REJECT(0x10000000, 0x1F000000),
> +
> + /*
> + * Data processing - Add/Substract Immediate:
> + * Encoding: xxx1 0001 xxxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_SINGLESTEP(0x11000000, 0x1F000000),
> +
> + /*
> + * Data processing
> + * Encoding:
> + * xxx1 0010 0xxx xxxx xxxx xxxx xxxx xxxx (Logical)
> + * xxx1 0010 1xxx xxxx xxxx xxxx xxxx xxxx (Move wide)
> + * xxx1 0011 0xxx xxxx xxxx xxxx xxxx xxxx (Bitfield)
> + * xxx1 0011 1xxx xxxx xxxx xxxx xxxx xxxx (Extract)
> + */
> + DECODE_SINGLESTEP(0x12000000, 0x1E000000),
> +
> + /*
> + * Data processing - SIMD/FP/AdvSIMD/Crypto-AES/SHA
> + * Encoding: xxx0 111x xxxx xxxx xxxx xxxx xxxx xxxx
> + * Encoding: xxx1 111x xxxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_SINGLESTEP(0x0E000000, 0x0E000000),
> +
> + /*
> + * Data processing - Register
> + * Encoding: xxxx 101x xxxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_SINGLESTEP(0x0A000000, 0x0E000000),
> +
> + /* Branching Instructions
> + *
> + * Encoding:
> + * x001 01xx xxxx xxxx xxxx xxxx xxxx xxxx (uncondtional Branch)
Unconditional
> + * x011 010x xxxx xxxx xxxx xxxx xxxx xxxx (compare & branch)
Compare (capitalisation)
> + * x011 011x xxxx xxxx xxxx xxxx xxxx xxxx (Test & Branch)
> + * 0101 010x xxxx xxxx xxxx xxxx xxxx xxxx (Conditional, immediate)
> + * 1101 011x xxxx xxxx xxxx xxxx xxxx xxxx (Unconditional,register)
> + */
> + DECODE_REJECT(0x14000000, 0x7C000000),
> + DECODE_REJECT(0x14000000, 0x7C000000),
> + DECODE_REJECT(0x34000000, 0x7E000000),
> + DECODE_REJECT(0x36000000, 0x7E000000),
> + DECODE_REJECT(0x54000000, 0xFE000000),
> + DECODE_REJECT(0xD6000000, 0xFE000000),
> +
> + /* System insn:
> + * Encoding: 1101 0101 00xx xxxx xxxx xxxx xxxx xxxx
> + *
> + * Note: MSR immediate (update PSTATE daif) is not safe handling
> + * within kprobes, rejected.
> + *
> + * Don't re-arrange these decode table entries.
> + */
> + DECODE_REJECT(0xD500401F, 0xFFF8F01F),
> + DECODE_SINGLESTEP(0xD5000000, 0xFFC00000),
> +
> + /* Exception Generation:
> + * Encoding: 1101 0100 xxxx xxxx xxxx xxxx xxxx xxxx
> + * Instructions: SVC, HVC, SMC, BRK, HLT, DCPS1, DCPS2, DCPS3
> + */
> + DECODE_REJECT(0xD4000000, 0xFF000000),
> +
> + /*
> + * Load/Store - Exclusive monitor
> + * Encoding: xx00 1000 xxxx xxxx xxxx xxxx xxxx xxxx
> + *
> + * Reject exlusive monitor'ed instructions
exclusive. Also, omit `monitor'ed' -- it doesn't mean anything.
> + */
> + DECODE_REJECT(0x08000000, 0x3F000000),
> +
> + /*
> + * Load/Store - PC relative(literal):
> + * Encoding: xx01 1x00 xxxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_REJECT(0x18000000, 0x3B000000),
> +
> + /*
> + * Load/Store - Register Pair
> + * Encoding:
> + * xx10 1x00 0xxx xxxx xxxx xxxx xxxx xxxx
> + * xx10 1x00 1xxx xxxx xxxx xxxx xxxx xxxx
> + * xx10 1x01 0xxx xxxx xxxx xxxx xxxx xxxx
> + * xx10 1x01 1xxx xxxx xxxx xxxx xxxx xxxx
> + */
> + DECODE_SINGLESTEP(0x28000000, 0x3A000000),
> +
> + /*
> + * Load/Store - Register
> + * Encoding:
> + * xx11 1x00 xx0x xxxx xxxx 00xx xxxx xxxx (unscaled imm)
> + * xx11 1x00 xx0x xxxx xxxx 01xx xxxx xxxx (imm post-indexed)
> + * xx11 1x00 xx0x xxxx xxxx 10xx xxxx xxxx (unpriviledged)
> + * xx11 1x00 xx0x xxxx xxxx 11xx xxxx xxxx (imm pre-indexed)
> + *
> + * xx11 1x00 xx10 xxxx xxxx xx10 xxxx xxxx (register offset)
> + *
> + * xx11 1x01 xxxx xxxx xxxx xxxx xxxx xxxx (unsigned imm)
> + */
> + DECODE_SINGLESTEP(0x38000000, 0x3B200000),
> + DECODE_SINGLESTEP(0x38200200, 0x38300300),
> + DECODE_SINGLESTEP(0x39000000, 0x3B000000),
> +
> + /*
> + * Load/Store - AdvSIMD
> + * Encoding:
> + * 0x00 1100 0x00 0000 xxxx xxxx xxxx xxxx (Multiple-structure)
> + * 0x00 1100 1x0x xxxx xxxx xxxx xxxx xxxx (Multi-struct post-indexed)
> + * 0x00 1101 0xx0 0000 xxxx xxxx xxxx xxxx (Single-structure))
> + * 0x00 1101 1xxx xxxx xxxx xxxx xxxx xxxx (Single-struct post-index)
> + */
> + DECODE_SINGLESTEP(0x0C000000, 0xBFBF0000),
> + DECODE_SINGLESTEP(0x0C800000, 0xBFA00000),
> + DECODE_SINGLESTEP(0x0D000000, 0xBF9F0000),
> + DECODE_SINGLESTEP(0x0D800000, 0xBF800000),
> +
> + /* Unallocated: xxx0 0xxx xxxx xxxx xxxx xxxx xxxx xxxx */
> + DECODE_REJECT(0x00000000, 0x18000000),
> + DECODE_END,
> +};
> +
> +static int __kprobes
> +kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
> + const struct aarch64_decode_item *tbl)
> +{
> + unsigned int entry, ret = INSN_REJECTED;
> +
> + for (entry = 0; !decode_table_end(tbl[entry]); entry++) {
> + if (decode_table_hit(tbl[entry], insn))
> + break;
> + }
> +
> + switch (decode_get_type(tbl[entry])) {
> + case DECODE_TYPE_END:
> + case DECODE_TYPE_REJECT:
> + default:
> + ret = INSN_REJECTED;
> + break;
> +
> + case DECODE_TYPE_SINGLESTEP:
> + ret = INSN_GOOD;
> + break;
> +
> + case DECODE_TYPE_SIMULATE:
> + ret = INSN_REJECTED;
> + break;
> +
> + case DECODE_TYPE_TABLE:
> + /* recurse with next level decode table */
> + ret = kprobe_decode_insn(insn, asi,
> + decode_sub_table(tbl[entry]));
> + };
> + return ret;
> +}
> +
> +/* Return:
> + * INSN_REJECTED If instruction is one not allowed to kprobe,
> + * INSN_GOOD If instruction is supported and uses instruction slot,
> + * INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
> + */
> +enum kprobe_insn __kprobes
> +arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
> +{
> + return kprobe_decode_insn(insn, asi, aarch64_decode_table);
> +}
> diff --git a/arch/arm64/kernel/kprobes-arm64.h b/arch/arm64/kernel/kprobes-arm64.h
> new file mode 100644
> index 0000000..87e7891
> --- /dev/null
> +++ b/arch/arm64/kernel/kprobes-arm64.h
> @@ -0,0 +1,28 @@
> +/*
> + * arch/arm64/kernel/kprobes-arm64.h
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _ARM_KERNEL_KPROBES_ARM64_H
> +#define _ARM_KERNEL_KPROBES_ARM64_H
> +
> +enum kprobe_insn {
> + INSN_REJECTED,
> + INSN_GOOD_NO_SLOT,
> + INSN_GOOD,
> +};
> +
> +enum kprobe_insn __kprobes
> +arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi);
> +
> +#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> new file mode 100644
> index 0000000..def10b6
> --- /dev/null
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -0,0 +1,538 @@
> +/*
> + * arch/arm64/kernel/kprobes.c
> + *
> + * Kprobes support for ARM64
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + */
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/stop_machine.h>
> +#include <linux/stringify.h>
> +#include <asm/traps.h>
> +#include <asm/cacheflush.h>
> +#include <asm/debug-monitors.h>
> +#include <asm/system_misc.h>
> +#include <asm/insn.h>
> +
> +#include "kprobes.h"
> +#include "kprobes-arm64.h"
> +
> +#define MIN_STACK_SIZE(addr) min((unsigned long)MAX_STACK_SIZE, \
> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr))
Why is this not defined along with MAX_STACK_SIZE?
> +DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> +DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> +
> +static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> +{
> + int i;
> + /* prepare insn slot */
> + p->ainsn.insn[0] = p->opcode;
> + /* NOP for superscalar uArch decode */
superscalar uArch?
> + for (i = 1; i < MAX_INSN_SIZE; i++)
> + p->ainsn.insn[i] = ARCH64_NOP_OPCODE;
Should be AARCH64 (yes, that's two adjacent 'A's!). Also, I think the
jump_label stuff had helpers to give you a NOP hint.
> +
> + flush_icache_range((uintptr_t) (p->ainsn.insn),
> + (uintptr_t) (p->ainsn.insn) + MAX_INSN_SIZE);
> +}
> +
> +int __kprobes arch_prepare_kprobe(struct kprobe *p)
> +{
> + kprobe_opcode_t insn;
> + unsigned long probe_addr = (unsigned long)p->addr;
> +
> + /* copy instruction */
> + insn = *p->addr;
> + p->opcode = insn;
> +
> + if (in_exception_text(probe_addr))
> + return -EINVAL;
> +
> + /* decode instruction */
> + switch (arm_kprobe_decode_insn(insn, &p->ainsn)) {
> + case INSN_REJECTED: /* insn not supported */
> + return -EINVAL;
> + break;
> +
> + case INSN_GOOD_NO_SLOT: /* insn need simulation */
> + return -EINVAL;
> + break;
> +
> + case INSN_GOOD: /* instruction uses slot */
> + p->ainsn.insn = get_insn_slot();
> + if (!p->ainsn.insn)
> + return -ENOMEM;
> + break;
> + };
> +
> + /* prepare the instruction */
> + arch_prepare_ss_slot(p);
> +
> + return 0;
> +}
> +
> +static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
> +{
> + void *addrs[1];
> + u32 insns[1];
> +
> + addrs[0] = (void *)addr;
> + insns[0] = (u32)opcode;
> +
> + return aarch64_insn_patch_text_sync(addrs, insns, 1);
> +}
> +
> +/* arm kprobe: install breakpoint in text */
> +void __kprobes arch_arm_kprobe(struct kprobe *p)
> +{
> + patch_text(p->addr, BRK64_OPCODE_KPROBES);
> +}
> +
> +/* disarm kprobe: remove breakpoint from text */
> +void __kprobes arch_disarm_kprobe(struct kprobe *p)
> +{
> + patch_text(p->addr, p->opcode);
> +}
> +
> +void __kprobes arch_remove_kprobe(struct kprobe *p)
> +{
> + if (p->ainsn.insn) {
> + free_insn_slot(p->ainsn.insn, 0);
> + p->ainsn.insn = NULL;
> + }
> +}
> +
> +static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
> +{
> + kcb->prev_kprobe.kp = kprobe_running();
> + kcb->prev_kprobe.status = kcb->kprobe_status;
> +}
> +
> +static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
> +{
> + __get_cpu_var(current_kprobe) = kcb->prev_kprobe.kp;
> + kcb->kprobe_status = kcb->prev_kprobe.status;
> +}
> +
> +static void __kprobes set_current_kprobe(struct kprobe *p)
> +{
> + __get_cpu_var(current_kprobe) = p;
> +}
__get_cpu_var uses were being cleaned up by Christoph recently. Take a look
in -next to see some examples of conversions over to this_cpu_*.
> +static void __kprobes
> +set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
> +{
> + kcb->ss_ctx.ss_status = KPROBES_STEP_PENDING;
> + kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
> +}
> +
> +static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
> +{
> + kcb->ss_ctx.ss_status = KPROBES_STEP_NONE;
> + kcb->ss_ctx.match_addr = 0;
> +}
> +
> +static void __kprobes
> +nop_singlestep_skip(struct kprobe *p, struct pt_regs *regs)
> +{
> + /* set return addr to next pc to continue */
> + instruction_pointer(regs) += sizeof(kprobe_opcode_t);
> + return;
> +}
> +
> +/* Mask/Unmask PSTATE.D flag
> + *
> + * Unmasking D-flag enables recursing into another debug
> + * exception (breakpoint or single step).
> + *
> + * Upon every exception entry, D-flag is disabled by the
> + * hardware. We shall unmask this flag only after safely
> + * saved the previous context and kprobes state machines.
> + *
> + * kprobes can generate recursing in breakpoint (followed
> + * by single stepping) within user-provided handlers only.
> + *
> + * All other places, keep the D-flag masked.
> + */
> +static void mask_pstate_debug_flag(u32 mask)
> +{
> + if (mask)
> + asm volatile("msr daifset, #9\n\t");
> + else
> + asm volatile("msr daifclr, #9\n\t");
> +}
NAK. Unmasking debug exceptions from within a debug exception is not safe.
I'd much rather we returned from handling this exception, then took whatever
other pending exception there was.
In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
places a hardware breakpoint on an instruction in the kernel for which
kprobes has patched in a brk. We take the hardware breakpoint, disable the
breakpoint and set up a single step before returning to the brk. The brk
then traps, but we must take care not to disable single-step and/or unmask
debug exceptions, because that will cause the hardware breakpoint code to
re-arm its breakpoint before we've stepped off the brk instruction.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-08 16:56 ` Will Deacon
@ 2013-11-09 9:10 ` Masami Hiramatsu
2013-11-11 5:39 ` Sandeepa Prabhu
2013-11-11 5:35 ` Sandeepa Prabhu
1 sibling, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-09 9:10 UTC (permalink / raw)
To: Will Deacon
Cc: Sandeepa Prabhu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, jiang.liu, Vijaya.Kumar
(2013/11/09 1:56), Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> since they both introduce some common instruction manipulation code. On the
> debug side, there will also be conflicts with the kgdb series, so it might
> make sense for us to merge those two first, then you can rebase on a stable
> branch from us.
[...]
> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> places a hardware breakpoint on an instruction in the kernel for which
> kprobes has patched in a brk. We take the hardware breakpoint, disable the
> breakpoint and set up a single step before returning to the brk. The brk
> then traps, but we must take care not to disable single-step and/or unmask
> debug exceptions, because that will cause the hardware breakpoint code to
> re-arm its breakpoint before we've stepped off the brk instruction.
Hmm, frankly to say, this kind of race issue is not seriously discussed
on x86 too, since kgdb is still a special tool (not used on the production
system).
I think under such situation kgdb operator must have full control of the
system, and he can (and has to) avoid such kind of race.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-09 9:10 ` Masami Hiramatsu
@ 2013-11-11 5:39 ` Sandeepa Prabhu
2013-11-11 7:54 ` Masami Hiramatsu
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-11 5:39 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu
On 9 November 2013 14:40, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/11/09 1:56), Will Deacon wrote:
>> Hi Sandeepa,
>>
>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>>> for ARM64.
>>
>> I think this series will conflict quite heavily with the jump_label series,
>> since they both introduce some common instruction manipulation code. On the
>> debug side, there will also be conflicts with the kgdb series, so it might
>> make sense for us to merge those two first, then you can rebase on a stable
>> branch from us.
>
> [...]
>
>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>> places a hardware breakpoint on an instruction in the kernel for which
>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
>> breakpoint and set up a single step before returning to the brk. The brk
>> then traps, but we must take care not to disable single-step and/or unmask
>> debug exceptions, because that will cause the hardware breakpoint code to
>> re-arm its breakpoint before we've stepped off the brk instruction.
>
> Hmm, frankly to say, this kind of race issue is not seriously discussed
> on x86 too, since kgdb is still a special tool (not used on the production
> system).
> I think under such situation kgdb operator must have full control of the
> system, and he can (and has to) avoid such kind of race.
Masami,
Hmm I think in same lines, but not sure if we expect kprobes to be
able to work fool-proof along with kgdb or hw breakpoints ?
Thanks,
Sandeepa
>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 5:39 ` Sandeepa Prabhu
@ 2013-11-11 7:54 ` Masami Hiramatsu
2013-11-11 10:51 ` Masami Hiramatsu
0 siblings, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-11 7:54 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/11 14:39), Sandeepa Prabhu wrote:
> On 9 November 2013 14:40, Masami Hiramatsu
> <masami.hiramatsu.pt@hitachi.com> wrote:
>> (2013/11/09 1:56), Will Deacon wrote:
>>> Hi Sandeepa,
>>>
>>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>>>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>>>> for ARM64.
>>>
>>> I think this series will conflict quite heavily with the jump_label series,
>>> since they both introduce some common instruction manipulation code. On the
>>> debug side, there will also be conflicts with the kgdb series, so it might
>>> make sense for us to merge those two first, then you can rebase on a stable
>>> branch from us.
>>
>> [...]
>>
>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>>> places a hardware breakpoint on an instruction in the kernel for which
>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
>>> breakpoint and set up a single step before returning to the brk. The brk
>>> then traps, but we must take care not to disable single-step and/or unmask
>>> debug exceptions, because that will cause the hardware breakpoint code to
>>> re-arm its breakpoint before we've stepped off the brk instruction.
>>
>> Hmm, frankly to say, this kind of race issue is not seriously discussed
>> on x86 too, since kgdb is still a special tool (not used on the production
>> system).
>> I think under such situation kgdb operator must have full control of the
>> system, and he can (and has to) avoid such kind of race.
> Masami,
>
> Hmm I think in same lines, but not sure if we expect kprobes to be
> able to work fool-proof along with kgdb or hw breakpoints ?
For hw breakpoint, yes, we finally get check each other to safely
use it even if one rejects the other one at some points(address).
Since the hw breakpoint is already open for normal user via perf,
we should do it. But the policy still needs to be discussed.
On the other hand, kgdb is a special case and it should be,
because, IMHO, kgdb is a debugger, which means that the kgdb
has to be able to monitor whole the kernel from outside. So
kprobes should not change its behavior even if used with kgdb.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 7:54 ` Masami Hiramatsu
@ 2013-11-11 10:51 ` Masami Hiramatsu
2013-11-11 10:58 ` Will Deacon
0 siblings, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-11 10:51 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Sandeepa Prabhu, Will Deacon, linux-arm-kernel, linux-kernel,
patches, linaro-kernel, Catalin Marinas, steve.capper, nico,
srikar, rostedt, dsaxena, Vijaya.Kumar, Jiang Liu,
yrl.pp-manager.tt, Peter Zijlstra, Ingo Molnar
(2013/11/11 16:54), Masami Hiramatsu wrote:
>>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>>>> places a hardware breakpoint on an instruction in the kernel for which
>>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
>>>> breakpoint and set up a single step before returning to the brk. The brk
>>>> then traps, but we must take care not to disable single-step and/or unmask
>>>> debug exceptions, because that will cause the hardware breakpoint code to
>>>> re-arm its breakpoint before we've stepped off the brk instruction.
>>>
>>> Hmm, frankly to say, this kind of race issue is not seriously discussed
>>> on x86 too, since kgdb is still a special tool (not used on the production
>>> system).
>>> I think under such situation kgdb operator must have full control of the
>>> system, and he can (and has to) avoid such kind of race.
>> Masami,
>>
>> Hmm I think in same lines, but not sure if we expect kprobes to be
>> able to work fool-proof along with kgdb or hw breakpoints ?
>
> For hw breakpoint, yes, we finally get check each other to safely
> use it even if one rejects the other one at some points(address).
> Since the hw breakpoint is already open for normal user via perf,
> we should do it. But the policy still needs to be discussed.
OK, I've ensured that the hw_breakpoint (from perf) can work
with kprobes (from ftrace) at the same address on x86.
So if arm64 already support hw_breakpoint on perf, kprobes should
work with it.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 10:51 ` Masami Hiramatsu
@ 2013-11-11 10:58 ` Will Deacon
2013-11-11 17:32 ` Masami Hiramatsu
2013-11-13 13:58 ` Peter Zijlstra
0 siblings, 2 replies; 50+ messages in thread
From: Will Deacon @ 2013-11-11 10:58 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Sandeepa Prabhu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On Mon, Nov 11, 2013 at 10:51:52AM +0000, Masami Hiramatsu wrote:
> (2013/11/11 16:54), Masami Hiramatsu wrote:
> >>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> >>>> places a hardware breakpoint on an instruction in the kernel for which
> >>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
> >>>> breakpoint and set up a single step before returning to the brk. The brk
> >>>> then traps, but we must take care not to disable single-step and/or unmask
> >>>> debug exceptions, because that will cause the hardware breakpoint code to
> >>>> re-arm its breakpoint before we've stepped off the brk instruction.
> >>>
> >>> Hmm, frankly to say, this kind of race issue is not seriously discussed
> >>> on x86 too, since kgdb is still a special tool (not used on the production
> >>> system).
> >>> I think under such situation kgdb operator must have full control of the
> >>> system, and he can (and has to) avoid such kind of race.
> >> Masami,
> >>
> >> Hmm I think in same lines, but not sure if we expect kprobes to be
> >> able to work fool-proof along with kgdb or hw breakpoints ?
> >
> > For hw breakpoint, yes, we finally get check each other to safely
> > use it even if one rejects the other one at some points(address).
> > Since the hw breakpoint is already open for normal user via perf,
> > we should do it. But the policy still needs to be discussed.
>
> OK, I've ensured that the hw_breakpoint (from perf) can work
> with kprobes (from ftrace) at the same address on x86.
> So if arm64 already support hw_breakpoint on perf, kprobes should
> work with it.
Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
ARM, we have to manually remove the breakpoint, perform a single-step, then
add the breakpoint again. If we re-enable debug exceptions in the kprobe
handler, the step will complete early and we'll never step off the
breakpoint.
Sandeepa: I think you need to retry Masami's test on the arm64 model, since
I'm fairly sure it won't work as expected without some additional code.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 10:58 ` Will Deacon
@ 2013-11-11 17:32 ` Masami Hiramatsu
2013-11-12 6:23 ` Sandeepa Prabhu
2013-11-13 13:58 ` Peter Zijlstra
1 sibling, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-11 17:32 UTC (permalink / raw)
To: Will Deacon
Cc: Sandeepa Prabhu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/11 19:58), Will Deacon wrote:
> On Mon, Nov 11, 2013 at 10:51:52AM +0000, Masami Hiramatsu wrote:
>> (2013/11/11 16:54), Masami Hiramatsu wrote:
>>>>>> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>>>>>> places a hardware breakpoint on an instruction in the kernel for which
>>>>>> kprobes has patched in a brk. We take the hardware breakpoint, disable the
>>>>>> breakpoint and set up a single step before returning to the brk. The brk
>>>>>> then traps, but we must take care not to disable single-step and/or unmask
>>>>>> debug exceptions, because that will cause the hardware breakpoint code to
>>>>>> re-arm its breakpoint before we've stepped off the brk instruction.
>>>>>
>>>>> Hmm, frankly to say, this kind of race issue is not seriously discussed
>>>>> on x86 too, since kgdb is still a special tool (not used on the production
>>>>> system).
>>>>> I think under such situation kgdb operator must have full control of the
>>>>> system, and he can (and has to) avoid such kind of race.
>>>> Masami,
>>>>
>>>> Hmm I think in same lines, but not sure if we expect kprobes to be
>>>> able to work fool-proof along with kgdb or hw breakpoints ?
>>>
>>> For hw breakpoint, yes, we finally get check each other to safely
>>> use it even if one rejects the other one at some points(address).
>>> Since the hw breakpoint is already open for normal user via perf,
>>> we should do it. But the policy still needs to be discussed.
>>
>> OK, I've ensured that the hw_breakpoint (from perf) can work
>> with kprobes (from ftrace) at the same address on x86.
>> So if arm64 already support hw_breakpoint on perf, kprobes should
>> work with it.
>
> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
> ARM, we have to manually remove the breakpoint, perform a single-step, then
> add the breakpoint again. If we re-enable debug exceptions in the kprobe
> handler, the step will complete early and we'll never step off the
> breakpoint.
I'm unsure about arm64's debug feature behavior, what does happen when
it performs a single-step on sw-breakpoint?
> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
> I'm fairly sure it won't work as expected without some additional code.
OK, anyway, for testing same one, we need to port ftrace first. So the next
plan is to make a kprobe module to put a probe (which just printk something)
on a specific function (e.g. vfs_symlink), and run perf record with
hw-breakpoint as below
$ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
Note that 0xXXXXXX is the address of vfs_symlink.
After that, you can see the message in dmesg and also check the perf result
with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
it works)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 17:32 ` Masami Hiramatsu
@ 2013-11-12 6:23 ` Sandeepa Prabhu
2013-11-12 7:27 ` Masami Hiramatsu
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-12 6:23 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>> with kprobes (from ftrace) at the same address on x86.
>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>> work with it.
>>
>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>> ARM, we have to manually remove the breakpoint, perform a single-step, then
>> add the breakpoint again. If we re-enable debug exceptions in the kprobe
>> handler, the step will complete early and we'll never step off the
>> breakpoint.
>
> I'm unsure about arm64's debug feature behavior, what does happen when
> it performs a single-step on sw-breakpoint?
>
>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>> I'm fairly sure it won't work as expected without some additional code.
>
> OK, anyway, for testing same one, we need to port ftrace first. So the next
> plan is to make a kprobe module to put a probe (which just printk something)
> on a specific function (e.g. vfs_symlink), and run perf record with
> hw-breakpoint as below
>
> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>
> Note that 0xXXXXXX is the address of vfs_symlink.
>
> After that, you can see the message in dmesg and also check the perf result
> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
> it works)
Thanks for steps, ARM64 ftrace patches are under review on arm mailing
list, I can contact the (linaro) developer implementing ftrace on
what's supported and then figure-out a way to test this concurrency of
kprobes breakpoint and hardware breakpoint.
Thanks,
Sandeepa
>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 6:23 ` Sandeepa Prabhu
@ 2013-11-12 7:27 ` Masami Hiramatsu
2013-11-12 8:44 ` Sandeepa Prabhu
2013-11-13 6:55 ` Sandeepa Prabhu
0 siblings, 2 replies; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-12 7:27 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar, Steven Rostedt
(2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>>> with kprobes (from ftrace) at the same address on x86.
>>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>>> work with it.
>>>
>>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>>> ARM, we have to manually remove the breakpoint, perform a single-step, then
>>> add the breakpoint again. If we re-enable debug exceptions in the kprobe
>>> handler, the step will complete early and we'll never step off the
>>> breakpoint.
>>
>> I'm unsure about arm64's debug feature behavior, what does happen when
>> it performs a single-step on sw-breakpoint?
>>
>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>> I'm fairly sure it won't work as expected without some additional code.
>>
>> OK, anyway, for testing same one, we need to port ftrace first. So the next
Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
can be done without ftrace port.
>> plan is to make a kprobe module to put a probe (which just printk something)
>> on a specific function (e.g. vfs_symlink), and run perf record with
>> hw-breakpoint as below
>>
>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>
>> Note that 0xXXXXXX is the address of vfs_symlink.
>>
>> After that, you can see the message in dmesg and also check the perf result
>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>> it works)
> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
> list, I can contact the (linaro) developer implementing ftrace on
> what's supported and then figure-out a way to test this concurrency of
> kprobes breakpoint and hardware breakpoint.
Would you mean this? :)
http://www.spinics.net/lists/arm-kernel/msg278477.html
Wow, it seems that this also has some works around instruction
manipulation (and confusable filenames...)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 7:27 ` Masami Hiramatsu
@ 2013-11-12 8:44 ` Sandeepa Prabhu
2013-11-12 10:17 ` Masami Hiramatsu
2013-11-13 6:55 ` Sandeepa Prabhu
1 sibling, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-12 8:44 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On 12 November 2013 12:57, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>>>> with kprobes (from ftrace) at the same address on x86.
>>>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>>>> work with it.
>>>>
>>>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>>>> ARM, we have to manually remove the breakpoint, perform a single-step, then
>>>> add the breakpoint again. If we re-enable debug exceptions in the kprobe
>>>> handler, the step will complete early and we'll never step off the
>>>> breakpoint.
>>>
>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>> it performs a single-step on sw-breakpoint?
>>>
>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>> I'm fairly sure it won't work as expected without some additional code.
>>>
>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>
> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
> can be done without ftrace port.
Yes, got it, all my verification until now are done using sample
modules only, looking out for perf (or some other mechanism: ptrace?)
that uses v8 hw breakpoint.
>
>>> plan is to make a kprobe module to put a probe (which just printk something)
>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>> hw-breakpoint as below
>>>
>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>
>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>
>>> After that, you can see the message in dmesg and also check the perf result
>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>> it works)
>> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
>> list, I can contact the (linaro) developer implementing ftrace on
>> what's supported and then figure-out a way to test this concurrency of
>> kprobes breakpoint and hardware breakpoint.
>
> Would you mean this? :)
> http://www.spinics.net/lists/arm-kernel/msg278477.html
>
> Wow, it seems that this also has some works around instruction
> manipulation (and confusable filenames...)
I referred to: http://lwn.net/Articles/572323/ which is another
implementation and on LAKML
>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 8:44 ` Sandeepa Prabhu
@ 2013-11-12 10:17 ` Masami Hiramatsu
2013-11-12 10:55 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-12 10:17 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/12 17:44), Sandeepa Prabhu wrote:
> On 12 November 2013 12:57, Masami Hiramatsu
> <masami.hiramatsu.pt@hitachi.com> wrote:
>> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>>>>> with kprobes (from ftrace) at the same address on x86.
>>>>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>>>>> work with it.
>>>>>
>>>>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>>>>> ARM, we have to manually remove the breakpoint, perform a single-step, then
>>>>> add the breakpoint again. If we re-enable debug exceptions in the kprobe
>>>>> handler, the step will complete early and we'll never step off the
>>>>> breakpoint.
>>>>
>>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>>> it performs a single-step on sw-breakpoint?
>>>>
>>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>>> I'm fairly sure it won't work as expected without some additional code.
>>>>
>>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>>
>> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
>> can be done without ftrace port.
> Yes, got it, all my verification until now are done using sample
> modules only, looking out for perf (or some other mechanism: ptrace?)
> that uses v8 hw breakpoint.
Yes, kprobe vs. perf and uprobe vs. ptrace :)
>>>> plan is to make a kprobe module to put a probe (which just printk something)
>>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>>> hw-breakpoint as below
>>>>
>>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>>
>>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>>
>>>> After that, you can see the message in dmesg and also check the perf result
>>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>>> it works)
>>> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
>>> list, I can contact the (linaro) developer implementing ftrace on
>>> what's supported and then figure-out a way to test this concurrency of
>>> kprobes breakpoint and hardware breakpoint.
>>
>> Would you mean this? :)
>> http://www.spinics.net/lists/arm-kernel/msg278477.html
>>
>> Wow, it seems that this also has some works around instruction
>> manipulation (and confusable filenames...)
> I referred to: http://lwn.net/Articles/572323/ which is another
> implementation and on LAKML
OK, I'll check that (and looks good at a glance).
By the way, I concern about Linaro guys who looks working a bit far
from the LKML and original feature maintainers. Please contact them,
I'm sure they don't bite your hand :)
BTW, I'm currently trying a general housecleaning of __kprobes
annotations. It may also have impact on your patch.
https://lkml.org/lkml/2013/11/8/187
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 10:17 ` Masami Hiramatsu
@ 2013-11-12 10:55 ` Sandeepa Prabhu
2013-11-12 14:11 ` Masami Hiramatsu
2013-11-12 16:59 ` Steven Rostedt
0 siblings, 2 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-12 10:55 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On 12 November 2013 15:47, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/11/12 17:44), Sandeepa Prabhu wrote:
>> On 12 November 2013 12:57, Masami Hiramatsu
>> <masami.hiramatsu.pt@hitachi.com> wrote:
>>> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>>>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>>>>>> with kprobes (from ftrace) at the same address on x86.
>>>>>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>>>>>> work with it.
>>>>>>
>>>>>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>>>>>> ARM, we have to manually remove the breakpoint, perform a single-step, then
>>>>>> add the breakpoint again. If we re-enable debug exceptions in the kprobe
>>>>>> handler, the step will complete early and we'll never step off the
>>>>>> breakpoint.
>>>>>
>>>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>>>> it performs a single-step on sw-breakpoint?
>>>>>
>>>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>>>> I'm fairly sure it won't work as expected without some additional code.
>>>>>
>>>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>>>
>>> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
>>> can be done without ftrace port.
>> Yes, got it, all my verification until now are done using sample
>> modules only, looking out for perf (or some other mechanism: ptrace?)
>> that uses v8 hw breakpoint.
>
> Yes, kprobe vs. perf and uprobe vs. ptrace :)
>
>
>>>>> plan is to make a kprobe module to put a probe (which just printk something)
>>>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>>>> hw-breakpoint as below
>>>>>
>>>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>>>
>>>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>>>
>>>>> After that, you can see the message in dmesg and also check the perf result
>>>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>>>> it works)
>>>> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
>>>> list, I can contact the (linaro) developer implementing ftrace on
>>>> what's supported and then figure-out a way to test this concurrency of
>>>> kprobes breakpoint and hardware breakpoint.
>>>
>>> Would you mean this? :)
>>> http://www.spinics.net/lists/arm-kernel/msg278477.html
>>>
>>> Wow, it seems that this also has some works around instruction
>>> manipulation (and confusable filenames...)
>> I referred to: http://lwn.net/Articles/572323/ which is another
>> implementation and on LAKML
>
> OK, I'll check that (and looks good at a glance).
> By the way, I concern about Linaro guys who looks working a bit far
> from the LKML and original feature maintainers. Please contact them,
> I'm sure they don't bite your hand :)
Hmm sure, will convey to our developers/leads :-)
>
> BTW, I'm currently trying a general housecleaning of __kprobes
> annotations. It may also have impact on your patch.
> https://lkml.org/lkml/2013/11/8/187
Hmm, we can help testing your patchset on arm64 platforms. Also have
many doubts on the changes you are working [blacklisting probes etc]
Basically I had tried placing kprobe on memcpy() and the model hung
(insmod never returned back!). Fast-model I have does not have option
of any debug so no clue what happened!.
memcpy() is low-level call being used internally within kprobes, so
probably we cannot handle probe on that routine, but then how to make
sure all such API are rejected by kprobe sub-system ?
~Sandeepa
>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 10:55 ` Sandeepa Prabhu
@ 2013-11-12 14:11 ` Masami Hiramatsu
2013-11-12 16:59 ` Steven Rostedt
1 sibling, 0 replies; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-12 14:11 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/12 19:55), Sandeepa Prabhu wrote:
>>>>> Thanks for steps, ARM64 ftrace patches are under review on arm mailing
>>>>> list, I can contact the (linaro) developer implementing ftrace on
>>>>> what's supported and then figure-out a way to test this concurrency of
>>>>> kprobes breakpoint and hardware breakpoint.
>>>>
>>>> Would you mean this? :)
>>>> http://www.spinics.net/lists/arm-kernel/msg278477.html
>>>>
>>>> Wow, it seems that this also has some works around instruction
>>>> manipulation (and confusable filenames...)
>>> I referred to: http://lwn.net/Articles/572323/ which is another
>>> implementation and on LAKML
>>
>> OK, I'll check that (and looks good at a glance).
>> By the way, I concern about Linaro guys who looks working a bit far
>> from the LKML and original feature maintainers. Please contact them,
>> I'm sure they don't bite your hand :)
> Hmm sure, will convey to our developers/leads :-)
Nice :)
>> BTW, I'm currently trying a general housecleaning of __kprobes
>> annotations. It may also have impact on your patch.
>> https://lkml.org/lkml/2013/11/8/187
> Hmm, we can help testing your patchset on arm64 platforms. Also have
> many doubts on the changes you are working [blacklisting probes etc]
>
> Basically I had tried placing kprobe on memcpy() and the model hung
> (insmod never returned back!). Fast-model I have does not have option
> of any debug so no clue what happened!.
On x86, I can probe memcpy() safely. It depends on the kprobes (and
breakpoint handling) implementation, and it could be found.
> memcpy() is low-level call being used internally within kprobes, so
> probably we cannot handle probe on that routine, but then how to make
> sure all such API are rejected by kprobe sub-system ?
I see, the blacklist still needs to be maintained. I periodically
run a test for probing each function on my kernel, and if I found
such problem, I added it on the blacklist.
Currently I run the test only on x86, so perhaps, other arch does
not have well tested yet.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 10:55 ` Sandeepa Prabhu
2013-11-12 14:11 ` Masami Hiramatsu
@ 2013-11-12 16:59 ` Steven Rostedt
2013-11-13 16:05 ` Masami Hiramatsu
1 sibling, 1 reply; 50+ messages in thread
From: Steven Rostedt @ 2013-11-12 16:59 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Masami Hiramatsu, Will Deacon, linux-arm-kernel, linux-kernel,
patches, linaro-kernel, Catalin Marinas, steve.capper, nico,
srikar, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On Tue, 12 Nov 2013 16:25:26 +0530
Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
> >
> > BTW, I'm currently trying a general housecleaning of __kprobes
> > annotations. It may also have impact on your patch.
> > https://lkml.org/lkml/2013/11/8/187
> Hmm, we can help testing your patchset on arm64 platforms. Also have
> many doubts on the changes you are working [blacklisting probes etc]
>
> Basically I had tried placing kprobe on memcpy() and the model hung
> (insmod never returned back!). Fast-model I have does not have option
> of any debug so no clue what happened!.
> memcpy() is low-level call being used internally within kprobes, so
> probably we cannot handle probe on that routine, but then how to make
> sure all such API are rejected by kprobe sub-system ?
Working on ports of ftrace, I found that many of the functions in lib/
are used by several locations that just can't be traced, due to how
low level they are. I just simply blacklisted the entire lib/
directory (See the top of lib/Makefile)
I wonder if there's an easy way to blacklist entire directories from
being used by kprobes too. Or at least do it by a file per file basis.
-- Steve
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 16:59 ` Steven Rostedt
@ 2013-11-13 16:05 ` Masami Hiramatsu
0 siblings, 0 replies; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-13 16:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sandeepa Prabhu, Will Deacon, linux-arm-kernel, linux-kernel,
patches, linaro-kernel, Catalin Marinas, steve.capper, nico,
srikar, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/13 1:59), Steven Rostedt wrote:
> On Tue, 12 Nov 2013 16:25:26 +0530
> Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>
>
>>>
>>> BTW, I'm currently trying a general housecleaning of __kprobes
>>> annotations. It may also have impact on your patch.
>>> https://lkml.org/lkml/2013/11/8/187
>> Hmm, we can help testing your patchset on arm64 platforms. Also have
>> many doubts on the changes you are working [blacklisting probes etc]
>>
>> Basically I had tried placing kprobe on memcpy() and the model hung
>> (insmod never returned back!). Fast-model I have does not have option
>> of any debug so no clue what happened!.
>> memcpy() is low-level call being used internally within kprobes, so
>> probably we cannot handle probe on that routine, but then how to make
>> sure all such API are rejected by kprobe sub-system ?
>
> Working on ports of ftrace, I found that many of the functions in lib/
> are used by several locations that just can't be traced, due to how
> low level they are. I just simply blacklisted the entire lib/
> directory (See the top of lib/Makefile)
>
> I wonder if there's an easy way to blacklist entire directories from
> being used by kprobes too. Or at least do it by a file per file basis.
Hm, perhaps we can do some magic in post-build script as kallsyms does.
1) make an object file
2) extract symbols from the file
3) put the symbols into data section as a list of strings
4) analyze the list at boot (init) time by using kallsyms
how about this? :)
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 7:27 ` Masami Hiramatsu
2013-11-12 8:44 ` Sandeepa Prabhu
@ 2013-11-13 6:55 ` Sandeepa Prabhu
2013-11-13 7:08 ` Sandeepa Prabhu
` (2 more replies)
1 sibling, 3 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-13 6:55 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>> it performs a single-step on sw-breakpoint?
>>>
>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>> I'm fairly sure it won't work as expected without some additional code.
>>>
>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>
> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
> can be done without ftrace port.
>
>>> plan is to make a kprobe module to put a probe (which just printk something)
>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>> hw-breakpoint as below
>>>
>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>
>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>
>>> After that, you can see the message in dmesg and also check the perf result
>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>> it works)
Hi Will, Masami,
I am not sure of 'perf' right now (my minimal rootfs doesn't have) but
I tried to test hardware breakpoints using sample modules
"samples/hw_breakpoint/" on arm64 upstream branch. This should use
same kernel api as perf I believe.
1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
triggering at all.
2. Placing text breakpoint (modified sample module with attr.bp_type
= HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
/tmp/foo". This time, breakpoint hit but exception is re-cursing
infinitely!
I have attached the kernel logs for reference. So wanted to check if
hw breakpoint/watch-points are working on the upstream branch? Has it
been tested recently with sample modules or perf/ptrace?
Thanks,
Sandeepa
[-- Attachment #2: kernel_aarch64_20131113-120837.log --]
[-- Type: text/x-log, Size: 117035 bytes --]
Initializing cgroup subsys cpu
Linux version 3.12.0-rc4+ (sandeepa@linaro-workstation) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #24 SMP PREEMPT Wed Nov 13 12:04:03 IST 2013
CPU: AArch64 Processor [410fd0f0] revision 0
Machine: RTSM_VE_AEMv8A
bootconsole [earlycon0] enabled
PERCPU: Embedded 10 pages/cpu @ffffffc87ffa8000 s11776 r8192 d20992 u40960
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
Kernel command line: console=ttyAMA0 root=/dev/mmcblk0p2 earlyprintk=pl011,0x1c090000 consolelog=9 rw
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
software IO TLB [mem 0x8f8000000-0x8fc000000] (64MB) mapped at [ffffffc878000000-ffffffc87bffffff]
Memory: 4058384K/4194304K available (3347K kernel code, 211K rwdata, 1164K rodata, 171K init, 154K bss, 135920K reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbc01c00000 - 0xffffffbc1f800000 ( 476 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc880000000 ( 34816 MB)
.init : 0xffffffc0004e9000 - 0xffffffc000513e00 ( 172 kB)
.text : 0xffffffc000080000 - 0xffffffc0004e8cf4 ( 4516 kB)
.data : 0xffffffc000514000 - 0xffffffc000548e80 ( 212 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:64 nr_irqs:64 0
Architected cp15 timer(s) running at 100.00MHz (phys).
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 9 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated.
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@3,00000000/sysctl@020000
vdso: 2 pages (1 code, 1 data) at base ffffffc000519000
hw-breakpoint: found 16 breakpoint and 16 watchpoint registers.
Serial: AMBA PL011 UART driver
1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled, bootconsole disabled
console [ttyAMA0] enabled, bootconsole disabled
1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38, base_baud = 0) is a PL011 rev2
1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39, base_baud = 0) is a PL011 rev2
1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40, base_baud = 0) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 7, 524288 bytes)
TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 4, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 936K (ffffffc010000000 - ffffffc0100ea000)
fuse init (API version 7.22)
msgmni has been set to 7928
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
<NUL>Freeing unused kernel memory: 168K (ffffffc0004e9000 - ffffffc000513000)
Wed Nov 18 01:00:00 UTC 2009
sh: can't access tty; job control turned off
/ #
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jkp\a\b^[[J\b^[[Jda\a\r/ # insmod data^[[J_\r/ # insmod data_breakpoint.ko ^[[Jf\b^[[Jksym=vfs_symlink
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ # ln -=s \b^[[J\b^[[J\b^[[Js /de\a\r/ # ln -s /de^[[Jv\r/ # ln -s /dev/^[[Jnull /tmp/a
/ # \r/ # ln -s /dev/null /tmp/a^[[J\b^[[Jn\b^[[Jb
/ # ls /tm\r/ # ls /tmp/^[[J
^[[1;36ma^[[0m ^[[1;36mb^[[0m ^[[1;34mlog^[[0m
/ #
/ #
/ #
/ # \r/ # ls /tmp/^[[J -al
total 0
drwxrwxrwt 3 0 0 100 Nov 18 01:00 ^[[1;34m.^[[0m
drwxrwxr-x 12 1000 1000 0 Nov 18 01:00 ^[[1;34m..^[[0m
lrwxrwxrwx 1 0 0 9 Nov 18 01:00 ^[[1;36ma^[[0m -> ^[[1;35m/dev/null^[[0m
lrwxrwxrwx 1 0 0 9 Nov 18 01:00 ^[[1;36mb^[[0m -> ^[[1;35m/dev/null^[[0m
drwxrwxrwx 2 0 0 40 Nov 18 01:00 ^[[1;34mlog^[[0m
/ # dmesg
Initializing cgroup subsys cpu
Linux version 3.12.0-rc4+ (sandeepa@linaro-workstation) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #24 SMP PREEMPT Wed Nov 13 12:04:03 IST 2013
CPU: AArch64 Processor [410fd0f0] revision 0
Machine: RTSM_VE_AEMv8A
bootconsole [earlycon0] enabled
On node 0 totalpages: 1048576
DMA32 zone: 7168 pages used for memmap
DMA32 zone: 0 pages reserved
DMA32 zone: 524288 pages, LIFO batch:31
Normal zone: 7168 pages used for memmap
Normal zone: 524288 pages, LIFO batch:31
PERCPU: Embedded 10 pages/cpu @ffffffc87ffa8000 s11776 r8192 d20992 u40960
pcpu-alloc: s11776 r8192 d20992 u40960 alloc=10*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
Kernel command line: console=ttyAMA0 root=/dev/mmcblk0p2 earlyprintk=pl011,0x1c090000 consolelog=9 rw
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
software IO TLB [mem 0x8f8000000-0x8fc000000] (64MB) mapped at [ffffffc878000000-ffffffc87bffffff]
Memory: 4058384K/4194304K available (3347K kernel code, 211K rwdata, 1164K rodata, 171K init, 154K bss, 135920K reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbc01c00000 - 0xffffffbc1f800000 ( 476 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc880000000 ( 34816 MB)
.init : 0xffffffc0004e9000 - 0xffffffc000513e00 ( 172 kB)
.text : 0xffffffc000080000 - 0xffffffc0004e8cf4 ( 4516 kB)
.data : 0xffffffc000514000 - 0xffffffc000548e80 ( 212 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:64 nr_irqs:64 0
Architected cp15 timer(s) running at 100.00MHz (phys).
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 9 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated.
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@3,00000000/sysctl@020000
vdso: 2 pages (1 code, 1 data) at base ffffffc000519000
hw-breakpoint: found 16 breakpoint and 16 watchpoint registers.
Serial: AMBA PL011 UART driver
1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled, bootconsole disabled
1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38, base_baud = 0) is a PL011 rev2
1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39, base_baud = 0) is a PL011 rev2
1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40, base_baud = 0) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 7, 524288 bytes)
TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 4, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 936K (ffffffc010000000 - ffffffc0100ea000)
fuse init (API version 7.22)
msgmni has been set to 7928
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
Freeing unused kernel memory: 168K (ffffffc0004e9000 - ffffffc000513000)
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ # rmm\r/ # rmmod ^[[Jda\a\r/ # rmmod data^[[J_\r/ # rmmod data_breakpoint.ko ^[[J
HW Breakpoint for vfs_symlink write uninstalled
/ #
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jte\r/ # insmod text_breakpoint.ko ^[[Jksym=bfs\b^[[J\b^[[J\b^[[Jvfs_symlink
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ #
/ #
/ #
/ #
/ # \r/ # insmod text_breakpoint.ko ksym=vfs_symlink^[[J\r/ # rmmod data_breakpoint.ko ^[[J\r/ # dmesg^[[J\r/ # ls /tmp/ -al^[[J\r/ # ls /tmp/^[[J\r/ # ln -s /dev/null /tmp/b^[[J\r/ # ln -s /dev/null /tmp/a^[[J\b^[[Jc
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 6:55 ` Sandeepa Prabhu
@ 2013-11-13 7:08 ` Sandeepa Prabhu
2013-11-13 14:07 ` Masami Hiramatsu
2013-11-13 14:31 ` Will Deacon
2 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-13 7:08 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
On 13 November 2013 12:25, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>>> it performs a single-step on sw-breakpoint?
>>>>
>>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>>> I'm fairly sure it won't work as expected without some additional code.
>>>>
>>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>>
>> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
>> can be done without ftrace port.
>>
>>>> plan is to make a kprobe module to put a probe (which just printk something)
>>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>>> hw-breakpoint as below
>>>>
>>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>>
>>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>>
>>>> After that, you can see the message in dmesg and also check the perf result
>>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>>> it works)
Hi Will, Masami,
I am not sure of 'perf' right now (my minimal rootfs doesn't have) but
I tried to test hardware breakpoints using sample modules
"samples/hw_breakpoint/" on arm64 upstream branch. This should use
same kernel api as perf I believe.
1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
triggering at all.
2. Placing text breakpoint (modified sample module with attr.bp_type
= HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
/tmp/foo". This time, breakpoint hit but exception is re-cursing
infinitely!
I have attached the kernel logs for reference. So wanted to check if
hw breakpoint/watch-points are working on the upstream branch? Has it
been tested recently with sample modules or perf/ptrace?
Thanks,
Sandeepa
[-- Attachment #2: kernel_aarch64_20131113-120837.log --]
[-- Type: text/x-log, Size: 31635 bytes --]
Initializing cgroup subsys cpu
Linux version 3.12.0-rc4+ (sandeepa@linaro-workstation) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #24 SMP PREEMPT Wed Nov 13 12:04:03 IST 2013
CPU: AArch64 Processor [410fd0f0] revision 0
Machine: RTSM_VE_AEMv8A
bootconsole [earlycon0] enabled
PERCPU: Embedded 10 pages/cpu @ffffffc87ffa8000 s11776 r8192 d20992 u40960
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
Kernel command line: console=ttyAMA0 root=/dev/mmcblk0p2 earlyprintk=pl011,0x1c090000 consolelog=9 rw
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
software IO TLB [mem 0x8f8000000-0x8fc000000] (64MB) mapped at [ffffffc878000000-ffffffc87bffffff]
Memory: 4058384K/4194304K available (3347K kernel code, 211K rwdata, 1164K rodata, 171K init, 154K bss, 135920K reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbc01c00000 - 0xffffffbc1f800000 ( 476 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc880000000 ( 34816 MB)
.init : 0xffffffc0004e9000 - 0xffffffc000513e00 ( 172 kB)
.text : 0xffffffc000080000 - 0xffffffc0004e8cf4 ( 4516 kB)
.data : 0xffffffc000514000 - 0xffffffc000548e80 ( 212 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:64 nr_irqs:64 0
Architected cp15 timer(s) running at 100.00MHz (phys).
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 9 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated.
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@3,00000000/sysctl@020000
vdso: 2 pages (1 code, 1 data) at base ffffffc000519000
hw-breakpoint: found 16 breakpoint and 16 watchpoint registers.
Serial: AMBA PL011 UART driver
1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled, bootconsole disabled
console [ttyAMA0] enabled, bootconsole disabled
1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38, base_baud = 0) is a PL011 rev2
1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39, base_baud = 0) is a PL011 rev2
1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40, base_baud = 0) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 7, 524288 bytes)
TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 4, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 936K (ffffffc010000000 - ffffffc0100ea000)
fuse init (API version 7.22)
msgmni has been set to 7928
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
<NUL>Freeing unused kernel memory: 168K (ffffffc0004e9000 - ffffffc000513000)
Wed Nov 18 01:00:00 UTC 2009
sh: can't access tty; job control turned off
/ #
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jkp\a\b^[[J\b^[[Jda\a\r/ # insmod data^[[J_\r/ # insmod data_breakpoint.ko ^[[Jf\b^[[Jksym=vfs_symlink
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ # ln -=s \b^[[J\b^[[J\b^[[Js /de\a\r/ # ln -s /de^[[Jv\r/ # ln -s /dev/^[[Jnull /tmp/a
/ # \r/ # ln -s /dev/null /tmp/a^[[J\b^[[Jn\b^[[Jb
/ # ls /tm\r/ # ls /tmp/^[[J
^[[1;36ma^[[0m ^[[1;36mb^[[0m ^[[1;34mlog^[[0m
/ #
/ #
/ #
/ # \r/ # ls /tmp/^[[J -al
total 0
drwxrwxrwt 3 0 0 100 Nov 18 01:00 ^[[1;34m.^[[0m
drwxrwxr-x 12 1000 1000 0 Nov 18 01:00 ^[[1;34m..^[[0m
lrwxrwxrwx 1 0 0 9 Nov 18 01:00 ^[[1;36ma^[[0m -> ^[[1;35m/dev/null^[[0m
lrwxrwxrwx 1 0 0 9 Nov 18 01:00 ^[[1;36mb^[[0m -> ^[[1;35m/dev/null^[[0m
drwxrwxrwx 2 0 0 40 Nov 18 01:00 ^[[1;34mlog^[[0m
/ # dmesg
Initializing cgroup subsys cpu
Linux version 3.12.0-rc4+ (sandeepa@linaro-workstation) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #24 SMP PREEMPT Wed Nov 13 12:04:03 IST 2013
CPU: AArch64 Processor [410fd0f0] revision 0
Machine: RTSM_VE_AEMv8A
bootconsole [earlycon0] enabled
On node 0 totalpages: 1048576
DMA32 zone: 7168 pages used for memmap
DMA32 zone: 0 pages reserved
DMA32 zone: 524288 pages, LIFO batch:31
Normal zone: 7168 pages used for memmap
Normal zone: 524288 pages, LIFO batch:31
PERCPU: Embedded 10 pages/cpu @ffffffc87ffa8000 s11776 r8192 d20992 u40960
pcpu-alloc: s11776 r8192 d20992 u40960 alloc=10*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
Kernel command line: console=ttyAMA0 root=/dev/mmcblk0p2 earlyprintk=pl011,0x1c090000 consolelog=9 rw
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
software IO TLB [mem 0x8f8000000-0x8fc000000] (64MB) mapped at [ffffffc878000000-ffffffc87bffffff]
Memory: 4058384K/4194304K available (3347K kernel code, 211K rwdata, 1164K rodata, 171K init, 154K bss, 135920K reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB)
vmemmap : 0xffffffbc01c00000 - 0xffffffbc1f800000 ( 476 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc880000000 ( 34816 MB)
.init : 0xffffffc0004e9000 - 0xffffffc000513e00 ( 172 kB)
.text : 0xffffffc000080000 - 0xffffffc0004e8cf4 ( 4516 kB)
.data : 0xffffffc000514000 - 0xffffffc000548e80 ( 212 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:64 nr_irqs:64 0
Architected cp15 timer(s) running at 100.00MHz (phys).
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 9 counters available
CPU1: Booted secondary processor
CPU2: Booted secondary processor
CPU3: Booted secondary processor
Brought up 4 CPUs
SMP: Total of 4 processors activated.
devtmpfs: initialized
atomic64 test passed
NET: Registered protocol family 16
of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@3,00000000/sysctl@020000
vdso: 2 pages (1 code, 1 data) at base ffffffc000519000
hw-breakpoint: found 16 breakpoint and 16 watchpoint registers.
Serial: AMBA PL011 UART driver
1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 37, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled, bootconsole disabled
1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 38, base_baud = 0) is a PL011 rev2
1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 39, base_baud = 0) is a PL011 rev2
1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 40, base_baud = 0) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 7, 524288 bytes)
TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 4, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 936K (ffffffc010000000 - ffffffc0100ea000)
fuse init (API version 7.22)
msgmni has been set to 7928
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
Freeing unused kernel memory: 168K (ffffffc0004e9000 - ffffffc000513000)
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ # rmm\r/ # rmmod ^[[Jda\a\r/ # rmmod data^[[J_\r/ # rmmod data_breakpoint.ko ^[[J
HW Breakpoint for vfs_symlink write uninstalled
/ #
/ #
/ #
/ #
/ # insm\r/ # insmod ^[[Jte\r/ # insmod text_breakpoint.ko ^[[Jksym=bfs\b^[[J\b^[[J\b^[[Jvfs_symlink
HW Breakpoint for vfs_symlink write installed
/ #
/ #
/ #
/ #
/ #
/ #
/ #
/ # \r/ # insmod text_breakpoint.ko ksym=vfs_symlink^[[J\r/ # rmmod data_breakpoint.ko ^[[J\r/ # dmesg^[[J\r/ # ls /tmp/ -al^[[J\r/ # ls /tmp/^[[J\r/ # ln -s /dev/null /tmp/b^[[J\r/ # ln -s /dev/null /tmp/a^[[J\b^[[Jc
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 7fd27ce0 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d00 ffffffc0 00159670 ffffffc0 7784ec00 ffffffc8 7f81f180 ffffffc0
7d00: 7fd27d20 ffffffc0 0013e010 ffffffc0 7784ec00 ffffffc8 00000000 00000000
7d20: 7fd27d40 ffffffc0 0013ec5c ffffffc0 00000600 00000000 7f81f180 ffffffc0
7d40: 7fd27d70 ffffffc0 0013ec88 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 00548d84 ffffffc0 00491788 ffffffc0 005132c0 ffffffc0 003bbaa0 ffffffc0
7d20: 7fd27d30 ffffffc0 003bbaac ffffffc0 7fd27e70 ffffffc0 00083630 ffffffc0
7d40: 7784ec00 ffffffc8 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
Call trace:
[<ffffffc00008718c>] dump_backtrace+0x0/0x12c
[<ffffffc0000872cc>] show_stack+0x14/0x1c
[<ffffffc0003b88e4>] dump_stack+0x70/0xac
[<ffffffbffc004020>] $x+0x20/0x34 [text_breakpoint]
[<ffffffc0000f8d40>] __perf_event_overflow+0xa4/0x214
[<ffffffc0000f9604>] perf_swevent_overflow+0x50/0x84
[<ffffffc0000f96f4>] perf_swevent_event+0xbc/0xc0
[<ffffffc0000f9938>] perf_bp_event+0x6c/0x78
[<ffffffc00008fd90>] breakpoint_handler+0xec/0x1d8
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc07fd27cb0 to 0xffffffc07fd27dd0)
7ca0: 7784ec00 ffffffc8 7fd44000 ffffffc0
7cc0: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 00512000 ffffffc0 00148400 ffffffc0
7ce0: 7fd27d20 ffffffc0 00081294 ffffffc0 0000200c ffffff80 7fd27d50 ffffffc0
7d00: 0055b8c0 ffffffc0 00002010 ffffff80 80000145 00000000 003bbaa0 ffffffc0
7d20: 7fd27e70 ffffffc0 000835c0 ffffffc0 7784ec00 ffffffc8 7fd44000 ffffffc0
7d40: 7fd27e70 ffffffc0 0013f9d8 ffffffc0 77784048 ffffffc8 7784ec00 ffffffc8
7d60: 7fd44020 ffffffc0 000003ea 00000000 7f81f180 ffffffc0 00556e58 ffffffc0
7d80: 7fd42000 ffffffc0 7fd42000 ffffffc0 00000000 00000000 ffb0c278 00000000
7da0: 00000001 00000000 00000000 00000000 00000000 00000000 ffb0c268 00000000
7dc0: 0007ee24 00000000 00000000 00000000
[<ffffffc0000834ac>] el1_dbg+0x10/0x60
[<ffffffc000143dc4>] SyS_symlink+0x14/0x1c
Dump stack from sample_hbp_handler
vfs_symlink value is changed
CPU: 2 PID: 463 Comm: ln Not tainted 3.12.0-rc4+ #24
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 6:55 ` Sandeepa Prabhu
2013-11-13 7:08 ` Sandeepa Prabhu
@ 2013-11-13 14:07 ` Masami Hiramatsu
2013-11-13 14:31 ` Will Deacon
2 siblings, 0 replies; 50+ messages in thread
From: Masami Hiramatsu @ 2013-11-13 14:07 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Will Deacon, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
(2013/11/13 15:55), Sandeepa Prabhu wrote:
>>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>>> it performs a single-step on sw-breakpoint?
>>>>
>>>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>>>>> I'm fairly sure it won't work as expected without some additional code.
>>>>
>>>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>>
>> Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
>> can be done without ftrace port.
>>
>>>> plan is to make a kprobe module to put a probe (which just printk something)
>>>> on a specific function (e.g. vfs_symlink), and run perf record with
>>>> hw-breakpoint as below
>>>>
>>>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>>>>
>>>> Note that 0xXXXXXX is the address of vfs_symlink.
>>>>
>>>> After that, you can see the message in dmesg and also check the perf result
>>>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>>>> it works)
> Hi Will, Masami,
>
> I am not sure of 'perf' right now (my minimal rootfs doesn't have) but
> I tried to test hardware breakpoints using sample modules
> "samples/hw_breakpoint/" on arm64 upstream branch. This should use
> same kernel api as perf I believe.
>
> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
> HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
> triggering at all.
> 2. Placing text breakpoint (modified sample module with attr.bp_type
> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
> /tmp/foo". This time, breakpoint hit but exception is re-cursing
> infinitely!
Did you this without kprobes? If so, the hw_breakpoint porting
on arm64 may have a bug.
> I have attached the kernel logs for reference. So wanted to check if
> hw breakpoint/watch-points are working on the upstream branch? Has it
> been tested recently with sample modules or perf/ptrace?
I've tested on x86 with the latest tip-tree kernel and it worked.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 6:55 ` Sandeepa Prabhu
2013-11-13 7:08 ` Sandeepa Prabhu
2013-11-13 14:07 ` Masami Hiramatsu
@ 2013-11-13 14:31 ` Will Deacon
2013-11-13 15:55 ` Sandeepa Prabhu
2 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-13 14:31 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Masami Hiramatsu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On Wed, Nov 13, 2013 at 06:55:33AM +0000, Sandeepa Prabhu wrote:
> >>> I'm unsure about arm64's debug feature behavior, what does happen when
> >>> it performs a single-step on sw-breakpoint?
> >>>
> >>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
> >>>> I'm fairly sure it won't work as expected without some additional code.
> >>>
> >>> OK, anyway, for testing same one, we need to port ftrace first. So the next
> >
> > Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
> > can be done without ftrace port.
> >
> >>> plan is to make a kprobe module to put a probe (which just printk something)
> >>> on a specific function (e.g. vfs_symlink), and run perf record with
> >>> hw-breakpoint as below
> >>>
> >>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
> >>>
> >>> Note that 0xXXXXXX is the address of vfs_symlink.
> >>>
> >>> After that, you can see the message in dmesg and also check the perf result
> >>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
> >>> it works)
> Hi Will, Masami,
>
> I am not sure of 'perf' right now (my minimal rootfs doesn't have) but
> I tried to test hardware breakpoints using sample modules
> "samples/hw_breakpoint/" on arm64 upstream branch. This should use
> same kernel api as perf I believe.
>
> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
> HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
> triggering at all.
vfs_symlink is a function. Why would you expect to write it?
> 2. Placing text breakpoint (modified sample module with attr.bp_type
> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
> /tmp/foo". This time, breakpoint hit but exception is re-cursing
> infinitely!
The problem here is that we expect the overflow handler to deal with the
stepping (like GDB does via ptrace). If you don't register a handler, the
kernel will do the step (like you would get if you used perf stat -e
mem:0xNNNN:x).
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 14:31 ` Will Deacon
@ 2013-11-13 15:55 ` Sandeepa Prabhu
2013-11-15 16:39 ` Will Deacon
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-13 15:55 UTC (permalink / raw)
To: Will Deacon
Cc: Masami Hiramatsu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On 13 November 2013 20:01, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Nov 13, 2013 at 06:55:33AM +0000, Sandeepa Prabhu wrote:
>> >>> I'm unsure about arm64's debug feature behavior, what does happen when
>> >>> it performs a single-step on sw-breakpoint?
>> >>>
>> >>>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since
>> >>>> I'm fairly sure it won't work as expected without some additional code.
>> >>>
>> >>> OK, anyway, for testing same one, we need to port ftrace first. So the next
>> >
>> > Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module
>> > can be done without ftrace port.
>> >
>> >>> plan is to make a kprobe module to put a probe (which just printk something)
>> >>> on a specific function (e.g. vfs_symlink), and run perf record with
>> >>> hw-breakpoint as below
>> >>>
>> >>> $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo
>> >>>
>> >>> Note that 0xXXXXXX is the address of vfs_symlink.
>> >>>
>> >>> After that, you can see the message in dmesg and also check the perf result
>> >>> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if
>> >>> it works)
>> Hi Will, Masami,
>>
>> I am not sure of 'perf' right now (my minimal rootfs doesn't have) but
>> I tried to test hardware breakpoints using sample modules
>> "samples/hw_breakpoint/" on arm64 upstream branch. This should use
>> same kernel api as perf I believe.
>>
>> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
>> HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
>> triggering at all.
>
> vfs_symlink is a function. Why would you expect to write it?
This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
which places watchpoint for bothe read/write.
Atleast watchpt should have triggered for Read right? I also tried
with othe functions like do_fork, vfs_read etc but no hit.
>
>> 2. Placing text breakpoint (modified sample module with attr.bp_type
>> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
>> /tmp/foo". This time, breakpoint hit but exception is re-cursing
>> infinitely!
>
> The problem here is that we expect the overflow handler to deal with the
> stepping (like GDB does via ptrace). If you don't register a handler, the
> kernel will do the step (like you would get if you used perf stat -e
> mem:0xNNNN:x).
[This test was done on upstream branch, without kprobes patches.]
Hmm, then this is expected with test breakpoint right? is this
handling to be done by perf and ptrace?
I did not see arm64 support in linux/tools/perf/, there are multiple
patches in mailing list though. Are you aware of any version of perf
that work with arm64?
~Sandeepa
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 15:55 ` Sandeepa Prabhu
@ 2013-11-15 16:39 ` Will Deacon
2013-11-18 6:55 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-15 16:39 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: Masami Hiramatsu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On Wed, Nov 13, 2013 at 03:55:42PM +0000, Sandeepa Prabhu wrote:
> On 13 November 2013 20:01, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Nov 13, 2013 at 06:55:33AM +0000, Sandeepa Prabhu wrote:
> >> 1. Placing watchpoint ( attr.bp_type = HW_BREAKPOINT_W |
> >> HW_BREAKPOINT_R) upon vfs_symlink symbol, but seems watch-point is not
> >> triggering at all.
> >
> > vfs_symlink is a function. Why would you expect to write it?
> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
> which places watchpoint for bothe read/write.
> Atleast watchpt should have triggered for Read right? I also tried
> with othe functions like do_fork, vfs_read etc but no hit.
You'd need to place something for exec if you want to see anything on the
instruction side. A read by the instruction fetcher does not trigger a read
watchpoint on ARM.
> >> 2. Placing text breakpoint (modified sample module with attr.bp_type
> >> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
> >> /tmp/foo". This time, breakpoint hit but exception is re-cursing
> >> infinitely!
> >
> > The problem here is that we expect the overflow handler to deal with the
> > stepping (like GDB does via ptrace). If you don't register a handler, the
> > kernel will do the step (like you would get if you used perf stat -e
> > mem:0xNNNN:x).
> [This test was done on upstream branch, without kprobes patches.]
> Hmm, then this is expected with test breakpoint right? is this
> handling to be done by perf and ptrace?
perf stat doesn't register an overflow handler, so the hw_breakpoint
backend will handle the step. ptrace registers a handler which sends a
SIGTRAP to the debugger (e.g. gdb), which handles the step manually
(probably using a PTRACE_SINGLESTEP request).
> I did not see arm64 support in linux/tools/perf/, there are multiple
> patches in mailing list though. Are you aware of any version of perf
> that work with arm64?
The perf tool should work fine on arm64 using mainline. Are you seeing
problems?
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-15 16:39 ` Will Deacon
@ 2013-11-18 6:55 ` Sandeepa Prabhu
2013-11-18 8:51 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-18 6:55 UTC (permalink / raw)
To: Will Deacon
Cc: Masami Hiramatsu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>> which places watchpoint for bothe read/write.
>> Atleast watchpt should have triggered for Read right? I also tried
>> with othe functions like do_fork, vfs_read etc but no hit.
>
> You'd need to place something for exec if you want to see anything on the
> instruction side. A read by the instruction fetcher does not trigger a read
> watchpoint on ARM.
Hmm, then watchpoint cannot not be placed on text address (instruction
fetch path) right?
(Sorry I did not check debug spec fully for watchpoint/hw breakpoints,
I should do that)
>
>> >> 2. Placing text breakpoint (modified sample module with attr.bp_type
>> >> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
>> >> /tmp/foo". This time, breakpoint hit but exception is re-cursing
>> >> infinitely!
>> >
>> > The problem here is that we expect the overflow handler to deal with the
>> > stepping (like GDB does via ptrace). If you don't register a handler, the
>> > kernel will do the step (like you would get if you used perf stat -e
>> > mem:0xNNNN:x).
>> [This test was done on upstream branch, without kprobes patches.]
>> Hmm, then this is expected with test breakpoint right? is this
>> handling to be done by perf and ptrace?
>
> perf stat doesn't register an overflow handler, so the hw_breakpoint
> backend will handle the step. ptrace registers a handler which sends a
> SIGTRAP to the debugger (e.g. gdb), which handles the step manually
> (probably using a PTRACE_SINGLESTEP request).
>
>> I did not see arm64 support in linux/tools/perf/, there are multiple
>> patches in mailing list though. Are you aware of any version of perf
>> that work with arm64?
>
> The perf tool should work fine on arm64 using mainline. Are you seeing
> problems?
Hmm basically perf is working and I can run tests now.
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-18 6:55 ` Sandeepa Prabhu
@ 2013-11-18 8:51 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-18 8:51 UTC (permalink / raw)
To: Will Deacon
Cc: Masami Hiramatsu, linux-arm-kernel, linux-kernel, patches,
linaro-kernel, Catalin Marinas, steve.capper, nico, srikar,
rostedt, dsaxena, Vijaya.Kumar, Jiang Liu, yrl.pp-manager.tt,
Peter Zijlstra, Ingo Molnar
On 18 November 2013 12:25, Sandeepa Prabhu <sandeepa.prabhu@linaro.org> wrote:
>>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>>> which places watchpoint for bothe read/write.
>>> Atleast watchpt should have triggered for Read right? I also tried
>>> with othe functions like do_fork, vfs_read etc but no hit.
>>
>> You'd need to place something for exec if you want to see anything on the
>> instruction side. A read by the instruction fetcher does not trigger a read
>> watchpoint on ARM.
> Hmm, then watchpoint cannot not be placed on text address (instruction
> fetch path) right?
> (Sorry I did not check debug spec fully for watchpoint/hw breakpoints,
> I should do that)
>
>>
>>> >> 2. Placing text breakpoint (modified sample module with attr.bp_type
>>> >> = HW_BREAKPOINT_X) upon vfs_symlink, and run "ln -s /dev/null
>>> >> /tmp/foo". This time, breakpoint hit but exception is re-cursing
>>> >> infinitely!
>>> >
>>> > The problem here is that we expect the overflow handler to deal with the
>>> > stepping (like GDB does via ptrace). If you don't register a handler, the
>>> > kernel will do the step (like you would get if you used perf stat -e
>>> > mem:0xNNNN:x).
>>> [This test was done on upstream branch, without kprobes patches.]
>>> Hmm, then this is expected with test breakpoint right? is this
>>> handling to be done by perf and ptrace?
>>
>> perf stat doesn't register an overflow handler, so the hw_breakpoint
>> backend will handle the step. ptrace registers a handler which sends a
>> SIGTRAP to the debugger (e.g. gdb), which handles the step manually
>> (probably using a PTRACE_SINGLESTEP request).
>>
>>> I did not see arm64 support in linux/tools/perf/, there are multiple
>>> patches in mailing list though. Are you aware of any version of perf
>>> that work with arm64?
>>
>> The perf tool should work fine on arm64 using mainline. Are you seeing
>> problems?
> Hmm basically perf is working and I can run tests now.
Hi Will,
Okay. I can see what you meant with respect to D-flag unmasking, on
original patchset(v2). :)
a. Placed a kprobe on vfs_read - works fine independently.
b. Placed hw_breakpoint on vfs_read using perf (perf record -e
mem:0xffffffc000134ba4:x -a -- sleep 10) and it works fine
independently.
c. Now, a+b, first placed kprobe on vfs_read and then ran perf record
event on vfs_read (hw breakpoint). Now, seeing that kprobe single step
is never complete/never disabled!, so debug exception would generate
forever! (Continuously printing "Unexpected kernel single-step
exception at EL1")
kprobe pre_handler: p->addr = 0xffffffc000134ba4
reenter_dbg: test API invoked
kprobe post_handler: p->addr = 0xffffffc000134ba4
fmp/fo^[[5Dreenter_dbg: test API invoked
kprobe pre_handler: p->addr = 0xffffffc000134ba4
Unexpected kernel single-step exception at EL1
Unexpected kernel single-step exception at EL1
....
Once I change the location of D-flag manipulation (your suggestion)
and run enough tests, I would come back with more details and inputs.
Thanks,
Sandeepa
>>
>> Will
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 10:58 ` Will Deacon
2013-11-11 17:32 ` Masami Hiramatsu
@ 2013-11-13 13:58 ` Peter Zijlstra
2013-11-13 14:20 ` Will Deacon
1 sibling, 1 reply; 50+ messages in thread
From: Peter Zijlstra @ 2013-11-13 13:58 UTC (permalink / raw)
To: Will Deacon
Cc: Masami Hiramatsu, Sandeepa Prabhu, linux-arm-kernel,
linux-kernel, patches, linaro-kernel, Catalin Marinas,
steve.capper, nico, srikar, rostedt, dsaxena, Vijaya.Kumar,
Jiang Liu, yrl.pp-manager.tt, Ingo Molnar
On Mon, Nov 11, 2013 at 10:58:12AM +0000, Will Deacon wrote:
> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
> ARM, we have to manually remove the breakpoint, perform a single-step, then
> add the breakpoint again. If we re-enable debug exceptions in the kprobe
> handler, the step will complete early and we'll never step off the
> breakpoint.
This is about hardware breakpoints right? Which are per-cpu? Otherwise
removing the breakpoint would open up a hole for another thread to slip
through while you're single stepping.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-13 13:58 ` Peter Zijlstra
@ 2013-11-13 14:20 ` Will Deacon
0 siblings, 0 replies; 50+ messages in thread
From: Will Deacon @ 2013-11-13 14:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Masami Hiramatsu, Sandeepa Prabhu, linux-arm-kernel,
linux-kernel, patches, linaro-kernel, Catalin Marinas,
steve.capper, nico, srikar, rostedt, dsaxena, Vijaya.Kumar,
Jiang Liu, yrl.pp-manager.tt, Ingo Molnar
On Wed, Nov 13, 2013 at 01:58:07PM +0000, Peter Zijlstra wrote:
> On Mon, Nov 11, 2013 at 10:58:12AM +0000, Will Deacon wrote:
> > Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
> > ARM, we have to manually remove the breakpoint, perform a single-step, then
> > add the breakpoint again. If we re-enable debug exceptions in the kprobe
> > handler, the step will complete early and we'll never step off the
> > breakpoint.
>
> This is about hardware breakpoints right? Which are per-cpu? Otherwise
> removing the breakpoint would open up a hole for another thread to slip
> through while you're single stepping.
Correct, but our hardware breakpoints don't have any resume feature, so they
have to be disabled on the relevant CPU, then stepped on that same CPU
before they can be reactivated.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-08 16:56 ` Will Deacon
2013-11-09 9:10 ` Masami Hiramatsu
@ 2013-11-11 5:35 ` Sandeepa Prabhu
2013-11-11 11:21 ` Will Deacon
1 sibling, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-11 5:35 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On 8 November 2013 22:26, Will Deacon <will.deacon@arm.com> wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> since they both introduce some common instruction manipulation code. On the
> debug side, there will also be conflicts with the kgdb series, so it might
> make sense for us to merge those two first, then you can rebase on a stable
> branch from us.
Yes, I understand, also the 3 features (kgdb, kprobes, jump_labels)
share some API dependencies.
I can rebase and re-post kprobes after the other 2 are merged.
The patch "[PATCH RFC v3 1/5] AArch64: Add single-step and breakpoint
handler hooks" will merge first along with kgdb?
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>> new file mode 100644
>> index 0000000..9b491d0
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -0,0 +1,59 @@
>> +/*
>> + * arch/arm64/include/asm/kprobes.h
>> + *
>> + * Copyright (C) 2013 Linaro Limited
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#ifndef _ARM_KPROBES_H
>> +#define _ARM_KPROBES_H
>> +
>> +#include <linux/types.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/percpu.h>
>> +
>> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>> +#define MAX_INSN_SIZE 2
>
> Why is this 2?
Second entry is to hold NOP instruction, absence of it cause abort
while instruction decode.
>
>> +#define MAX_STACK_SIZE 128
>> +
>> +#define flush_insn_slot(p) do { } while (0)
>> +#define kretprobe_blacklist_size 0
>> +
>> +#include <asm/probes.h>
>> +
>> +struct prev_kprobe {
>> + struct kprobe *kp;
>> + unsigned int status;
>> +};
>> +
>> +/* Single step context for kprobe */
>> +struct kprobe_step_ctx {
>> +#define KPROBES_STEP_NONE 0x0
>> +#define KPROBES_STEP_PENDING 0x1
>
> Maybe use an enum to stay consistent with what you did for pc_restore_t?
OK, I will change it to enums.
>
>> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
>> new file mode 100644
>> index 0000000..30d1c14
>> --- /dev/null
>> +++ b/arch/arm64/kernel/kprobes-arm64.c
>> @@ -0,0 +1,211 @@
>> +/*
>> + * arch/arm64/kernel/kprobes-arm64.c
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +#include <asm/kprobes.h>
>> +
>> +#include "probes-decode.h"
>> +#include "kprobes-arm64.h"
>> +
>> +/* AArch64 instruction decode table for kprobes:
>> + * The instruction will fall into one of the 3 groups:
>> + * 1. Single stepped out-of-the-line slot.
>> + * -Most instructions fall in this group, those does not
>> + * depend on PC address.
>> + *
>> + * 2. Should be simulated because of PC-relative/literal access.
>> + * -All branching and PC-relative insrtcutions are simulated
>> + * in C code, making use of saved pt_regs
>> + * Catch: SIMD/NEON register context are not saved while
>> + * entering debug exception, so are rejected for now.
>> + *
>> + * 3. Cannot be probed(not safe) so are rejected.
>> + * - Exception generation and exception return instructions
>> + * - Exclusive monitor(LDREX/STREX family)
>> + *
>> + */
>> +static const struct aarch64_decode_item aarch64_decode_table[] = {
>> + /*
>> + * Data processing - PC relative(literal) addressing:
>> + * Encoding: xxx1 0000 xxxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_REJECT(0x10000000, 0x1F000000),
>> +
>> + /*
>> + * Data processing - Add/Substract Immediate:
>> + * Encoding: xxx1 0001 xxxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_SINGLESTEP(0x11000000, 0x1F000000),
>> +
>> + /*
>> + * Data processing
>> + * Encoding:
>> + * xxx1 0010 0xxx xxxx xxxx xxxx xxxx xxxx (Logical)
>> + * xxx1 0010 1xxx xxxx xxxx xxxx xxxx xxxx (Move wide)
>> + * xxx1 0011 0xxx xxxx xxxx xxxx xxxx xxxx (Bitfield)
>> + * xxx1 0011 1xxx xxxx xxxx xxxx xxxx xxxx (Extract)
>> + */
>> + DECODE_SINGLESTEP(0x12000000, 0x1E000000),
>> +
>> + /*
>> + * Data processing - SIMD/FP/AdvSIMD/Crypto-AES/SHA
>> + * Encoding: xxx0 111x xxxx xxxx xxxx xxxx xxxx xxxx
>> + * Encoding: xxx1 111x xxxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_SINGLESTEP(0x0E000000, 0x0E000000),
>> +
>> + /*
>> + * Data processing - Register
>> + * Encoding: xxxx 101x xxxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_SINGLESTEP(0x0A000000, 0x0E000000),
>> +
>> + /* Branching Instructions
>> + *
>> + * Encoding:
>> + * x001 01xx xxxx xxxx xxxx xxxx xxxx xxxx (uncondtional Branch)
>
> Unconditional
OK, I will make all the descriptions consistent (capitalised).
>
>> + * x011 010x xxxx xxxx xxxx xxxx xxxx xxxx (compare & branch)
>
> Compare (capitalisation)
>
>> + * x011 011x xxxx xxxx xxxx xxxx xxxx xxxx (Test & Branch)
>> + * 0101 010x xxxx xxxx xxxx xxxx xxxx xxxx (Conditional, immediate)
>> + * 1101 011x xxxx xxxx xxxx xxxx xxxx xxxx (Unconditional,register)
>> + */
>> + DECODE_REJECT(0x14000000, 0x7C000000),
>> + DECODE_REJECT(0x14000000, 0x7C000000),
>> + DECODE_REJECT(0x34000000, 0x7E000000),
>> + DECODE_REJECT(0x36000000, 0x7E000000),
>> + DECODE_REJECT(0x54000000, 0xFE000000),
>> + DECODE_REJECT(0xD6000000, 0xFE000000),
>> +
>> + /* System insn:
>> + * Encoding: 1101 0101 00xx xxxx xxxx xxxx xxxx xxxx
>> + *
>> + * Note: MSR immediate (update PSTATE daif) is not safe handling
>> + * within kprobes, rejected.
>> + *
>> + * Don't re-arrange these decode table entries.
>> + */
>> + DECODE_REJECT(0xD500401F, 0xFFF8F01F),
>> + DECODE_SINGLESTEP(0xD5000000, 0xFFC00000),
>> +
>> + /* Exception Generation:
>> + * Encoding: 1101 0100 xxxx xxxx xxxx xxxx xxxx xxxx
>> + * Instructions: SVC, HVC, SMC, BRK, HLT, DCPS1, DCPS2, DCPS3
>> + */
>> + DECODE_REJECT(0xD4000000, 0xFF000000),
>> +
>> + /*
>> + * Load/Store - Exclusive monitor
>> + * Encoding: xx00 1000 xxxx xxxx xxxx xxxx xxxx xxxx
>> + *
>> + * Reject exlusive monitor'ed instructions
>
> exclusive. Also, omit `monitor'ed' -- it doesn't mean anything.
Sure.
>
>> + */
>> + DECODE_REJECT(0x08000000, 0x3F000000),
>> +
>> + /*
>> + * Load/Store - PC relative(literal):
>> + * Encoding: xx01 1x00 xxxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_REJECT(0x18000000, 0x3B000000),
>> +
>> + /*
>> + * Load/Store - Register Pair
>> + * Encoding:
>> + * xx10 1x00 0xxx xxxx xxxx xxxx xxxx xxxx
>> + * xx10 1x00 1xxx xxxx xxxx xxxx xxxx xxxx
>> + * xx10 1x01 0xxx xxxx xxxx xxxx xxxx xxxx
>> + * xx10 1x01 1xxx xxxx xxxx xxxx xxxx xxxx
>> + */
>> + DECODE_SINGLESTEP(0x28000000, 0x3A000000),
>> +
>> + /*
>> + * Load/Store - Register
>> + * Encoding:
>> + * xx11 1x00 xx0x xxxx xxxx 00xx xxxx xxxx (unscaled imm)
>> + * xx11 1x00 xx0x xxxx xxxx 01xx xxxx xxxx (imm post-indexed)
>> + * xx11 1x00 xx0x xxxx xxxx 10xx xxxx xxxx (unpriviledged)
>> + * xx11 1x00 xx0x xxxx xxxx 11xx xxxx xxxx (imm pre-indexed)
>> + *
>> + * xx11 1x00 xx10 xxxx xxxx xx10 xxxx xxxx (register offset)
>> + *
>> + * xx11 1x01 xxxx xxxx xxxx xxxx xxxx xxxx (unsigned imm)
>> + */
>> + DECODE_SINGLESTEP(0x38000000, 0x3B200000),
>> + DECODE_SINGLESTEP(0x38200200, 0x38300300),
>> + DECODE_SINGLESTEP(0x39000000, 0x3B000000),
>> +
>> + /*
>> + * Load/Store - AdvSIMD
>> + * Encoding:
>> + * 0x00 1100 0x00 0000 xxxx xxxx xxxx xxxx (Multiple-structure)
>> + * 0x00 1100 1x0x xxxx xxxx xxxx xxxx xxxx (Multi-struct post-indexed)
>> + * 0x00 1101 0xx0 0000 xxxx xxxx xxxx xxxx (Single-structure))
>> + * 0x00 1101 1xxx xxxx xxxx xxxx xxxx xxxx (Single-struct post-index)
>> + */
>> + DECODE_SINGLESTEP(0x0C000000, 0xBFBF0000),
>> + DECODE_SINGLESTEP(0x0C800000, 0xBFA00000),
>> + DECODE_SINGLESTEP(0x0D000000, 0xBF9F0000),
>> + DECODE_SINGLESTEP(0x0D800000, 0xBF800000),
>> +
>> + /* Unallocated: xxx0 0xxx xxxx xxxx xxxx xxxx xxxx xxxx */
>> + DECODE_REJECT(0x00000000, 0x18000000),
>> + DECODE_END,
>> +};
>> +
>> +static int __kprobes
>> +kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>> + const struct aarch64_decode_item *tbl)
>> +{
>> + unsigned int entry, ret = INSN_REJECTED;
>> +
>> + for (entry = 0; !decode_table_end(tbl[entry]); entry++) {
>> + if (decode_table_hit(tbl[entry], insn))
>> + break;
>> + }
>> +
>> + switch (decode_get_type(tbl[entry])) {
>> + case DECODE_TYPE_END:
>> + case DECODE_TYPE_REJECT:
>> + default:
>> + ret = INSN_REJECTED;
>> + break;
>> +
>> + case DECODE_TYPE_SINGLESTEP:
>> + ret = INSN_GOOD;
>> + break;
>> +
>> + case DECODE_TYPE_SIMULATE:
>> + ret = INSN_REJECTED;
>> + break;
>> +
>> + case DECODE_TYPE_TABLE:
>> + /* recurse with next level decode table */
>> + ret = kprobe_decode_insn(insn, asi,
>> + decode_sub_table(tbl[entry]));
>> + };
>> + return ret;
>> +}
>> +
>> +/* Return:
>> + * INSN_REJECTED If instruction is one not allowed to kprobe,
>> + * INSN_GOOD If instruction is supported and uses instruction slot,
>> + * INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
>> + */
>> +enum kprobe_insn __kprobes
>> +arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>> +{
>> + return kprobe_decode_insn(insn, asi, aarch64_decode_table);
>> +}
>> diff --git a/arch/arm64/kernel/kprobes-arm64.h b/arch/arm64/kernel/kprobes-arm64.h
>> new file mode 100644
>> index 0000000..87e7891
>> --- /dev/null
>> +++ b/arch/arm64/kernel/kprobes-arm64.h
>> @@ -0,0 +1,28 @@
>> +/*
>> + * arch/arm64/kernel/kprobes-arm64.h
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#ifndef _ARM_KERNEL_KPROBES_ARM64_H
>> +#define _ARM_KERNEL_KPROBES_ARM64_H
>> +
>> +enum kprobe_insn {
>> + INSN_REJECTED,
>> + INSN_GOOD_NO_SLOT,
>> + INSN_GOOD,
>> +};
>> +
>> +enum kprobe_insn __kprobes
>> +arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi);
>> +
>> +#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
>> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
>> new file mode 100644
>> index 0000000..def10b6
>> --- /dev/null
>> +++ b/arch/arm64/kernel/kprobes.c
>> @@ -0,0 +1,538 @@
>> +/*
>> + * arch/arm64/kernel/kprobes.c
>> + *
>> + * Kprobes support for ARM64
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + * Author: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/stop_machine.h>
>> +#include <linux/stringify.h>
>> +#include <asm/traps.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/debug-monitors.h>
>> +#include <asm/system_misc.h>
>> +#include <asm/insn.h>
>> +
>> +#include "kprobes.h"
>> +#include "kprobes-arm64.h"
>> +
>> +#define MIN_STACK_SIZE(addr) min((unsigned long)MAX_STACK_SIZE, \
>> + (unsigned long)current_thread_info() + THREAD_START_SP - (addr))
>
> Why is this not defined along with MAX_STACK_SIZE?
Hmm can be move to header file.
>
>> +DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>> +DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> +
>> +static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> +{
>> + int i;
>> + /* prepare insn slot */
>> + p->ainsn.insn[0] = p->opcode;
>> + /* NOP for superscalar uArch decode */
>
> superscalar uArch?
well, the comment needs refining, what we mean is that one NOP should
follow the instruction in memory slot, for the decode stage(not to hit
undefined instruction).
>
>> + for (i = 1; i < MAX_INSN_SIZE; i++)
>> + p->ainsn.insn[i] = ARCH64_NOP_OPCODE;
>
> Should be AARCH64 (yes, that's two adjacent 'A's!). Also, I think the
> jump_label stuff had helpers to give you a NOP hint.
will check, all we need here is 'opcode' value to fill-in the memory location.
>
>> +
>> + flush_icache_range((uintptr_t) (p->ainsn.insn),
>> + (uintptr_t) (p->ainsn.insn) + MAX_INSN_SIZE);
>> +}
>> +
>> +int __kprobes arch_prepare_kprobe(struct kprobe *p)
>> +{
>> + kprobe_opcode_t insn;
>> + unsigned long probe_addr = (unsigned long)p->addr;
>> +
>> + /* copy instruction */
>> + insn = *p->addr;
>> + p->opcode = insn;
>> +
>> + if (in_exception_text(probe_addr))
>> + return -EINVAL;
>> +
>> + /* decode instruction */
>> + switch (arm_kprobe_decode_insn(insn, &p->ainsn)) {
>> + case INSN_REJECTED: /* insn not supported */
>> + return -EINVAL;
>> + break;
>> +
>> + case INSN_GOOD_NO_SLOT: /* insn need simulation */
>> + return -EINVAL;
>> + break;
>> +
>> + case INSN_GOOD: /* instruction uses slot */
>> + p->ainsn.insn = get_insn_slot();
>> + if (!p->ainsn.insn)
>> + return -ENOMEM;
>> + break;
>> + };
>> +
>> + /* prepare the instruction */
>> + arch_prepare_ss_slot(p);
>> +
>> + return 0;
>> +}
>> +
>> +static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
>> +{
>> + void *addrs[1];
>> + u32 insns[1];
>> +
>> + addrs[0] = (void *)addr;
>> + insns[0] = (u32)opcode;
>> +
>> + return aarch64_insn_patch_text_sync(addrs, insns, 1);
>> +}
>> +
>> +/* arm kprobe: install breakpoint in text */
>> +void __kprobes arch_arm_kprobe(struct kprobe *p)
>> +{
>> + patch_text(p->addr, BRK64_OPCODE_KPROBES);
>> +}
>> +
>> +/* disarm kprobe: remove breakpoint from text */
>> +void __kprobes arch_disarm_kprobe(struct kprobe *p)
>> +{
>> + patch_text(p->addr, p->opcode);
>> +}
>> +
>> +void __kprobes arch_remove_kprobe(struct kprobe *p)
>> +{
>> + if (p->ainsn.insn) {
>> + free_insn_slot(p->ainsn.insn, 0);
>> + p->ainsn.insn = NULL;
>> + }
>> +}
>> +
>> +static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
>> +{
>> + kcb->prev_kprobe.kp = kprobe_running();
>> + kcb->prev_kprobe.status = kcb->kprobe_status;
>> +}
>> +
>> +static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
>> +{
>> + __get_cpu_var(current_kprobe) = kcb->prev_kprobe.kp;
>> + kcb->kprobe_status = kcb->prev_kprobe.status;
>> +}
>> +
>> +static void __kprobes set_current_kprobe(struct kprobe *p)
>> +{
>> + __get_cpu_var(current_kprobe) = p;
>> +}
>
> __get_cpu_var uses were being cleaned up by Christoph recently. Take a look
> in -next to see some examples of conversions over to this_cpu_*.
Ok, would check this, can change in next version of the patch.
>
>> +static void __kprobes
>> +set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
>> +{
>> + kcb->ss_ctx.ss_status = KPROBES_STEP_PENDING;
>> + kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
>> +}
>> +
>> +static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
>> +{
>> + kcb->ss_ctx.ss_status = KPROBES_STEP_NONE;
>> + kcb->ss_ctx.match_addr = 0;
>> +}
>> +
>> +static void __kprobes
>> +nop_singlestep_skip(struct kprobe *p, struct pt_regs *regs)
>> +{
>> + /* set return addr to next pc to continue */
>> + instruction_pointer(regs) += sizeof(kprobe_opcode_t);
>> + return;
>> +}
>> +
>> +/* Mask/Unmask PSTATE.D flag
>> + *
>> + * Unmasking D-flag enables recursing into another debug
>> + * exception (breakpoint or single step).
>> + *
>> + * Upon every exception entry, D-flag is disabled by the
>> + * hardware. We shall unmask this flag only after safely
>> + * saved the previous context and kprobes state machines.
>> + *
>> + * kprobes can generate recursing in breakpoint (followed
>> + * by single stepping) within user-provided handlers only.
>> + *
>> + * All other places, keep the D-flag masked.
>> + */
>> +static void mask_pstate_debug_flag(u32 mask)
>> +{
>> + if (mask)
>> + asm volatile("msr daifset, #9\n\t");
>> + else
>> + asm volatile("msr daifclr, #9\n\t");
>> +}
>
> NAK. Unmasking debug exceptions from within a debug exception is not safe.
> I'd much rather we returned from handling this exception, then took whatever
> other pending exception there was.
well, kprobes needs recursive breakpoints to be handled, and I am not
sure if this can be achieved other way than unmasking D-flag for a
shorter duration where we can expect re-entry (I would check if this
can be done without re-cursing)
I want to understand why unmasking D-flag is unsafe here, kprobes make
sure that recursion depth is only 2 (i.e. does not generate 3rd
Breakpoint trap) and interrupts are kept masked while recursion/single
stepping. Is it unsafe only if conflict with hardware breakpoint on
same CPU?
>
> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> places a hardware breakpoint on an instruction in the kernel for which
> kprobes has patched in a brk. We take the hardware breakpoint, disable the
> breakpoint and set up a single step before returning to the brk. The brk
> then traps, but we must take care not to disable single-step and/or unmask
> debug exceptions, because that will cause the hardware breakpoint code to
> re-arm its breakpoint before we've stepped off the brk instruction.
Not sure if kprobes can work together with hardware breakpoint or kgdb
when multiple breakpoints (h/w and s/w) are placed on same text
address. How arm32 and x86 handle this kind of scenario?
Probably, the person debugging hardware breakpoint or kgdb should have
control over the flow and disable kprobes (sysfs interface available)?
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 5:35 ` Sandeepa Prabhu
@ 2013-11-11 11:21 ` Will Deacon
2013-11-12 6:52 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-11 11:21 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On Mon, Nov 11, 2013 at 05:35:37AM +0000, Sandeepa Prabhu wrote:
> On 8 November 2013 22:26, Will Deacon <will.deacon@arm.com> wrote:
> >> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> >> new file mode 100644
> >> index 0000000..9b491d0
> >> --- /dev/null
> >> +++ b/arch/arm64/include/asm/kprobes.h
> >> @@ -0,0 +1,59 @@
> >> +/*
> >> + * arch/arm64/include/asm/kprobes.h
> >> + *
> >> + * Copyright (C) 2013 Linaro Limited
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >> + * General Public License for more details.
> >> + */
> >> +
> >> +#ifndef _ARM_KPROBES_H
> >> +#define _ARM_KPROBES_H
> >> +
> >> +#include <linux/types.h>
> >> +#include <linux/ptrace.h>
> >> +#include <linux/percpu.h>
> >> +
> >> +#define __ARCH_WANT_KPROBES_INSN_SLOT
> >> +#define MAX_INSN_SIZE 2
> >
> > Why is this 2?
> Second entry is to hold NOP instruction, absence of it cause abort
> while instruction decode.
Hmm, can you elaborate please? I'm not sure why you should get an abort
decoding kernel addresses.
> >> +DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> >> +DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
> >> +
> >> +static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
> >> +{
> >> + int i;
> >> + /* prepare insn slot */
> >> + p->ainsn.insn[0] = p->opcode;
> >> + /* NOP for superscalar uArch decode */
> >
> > superscalar uArch?
> well, the comment needs refining, what we mean is that one NOP should
> follow the instruction in memory slot, for the decode stage(not to hit
> undefined instruction).
Is this undef related to your comment above?
> > NAK. Unmasking debug exceptions from within a debug exception is not safe.
> > I'd much rather we returned from handling this exception, then took whatever
> > other pending exception there was.
> well, kprobes needs recursive breakpoints to be handled, and I am not
> sure if this can be achieved other way than unmasking D-flag for a
> shorter duration where we can expect re-entry (I would check if this
> can be done without re-cursing)
> I want to understand why unmasking D-flag is unsafe here, kprobes make
> sure that recursion depth is only 2 (i.e. does not generate 3rd
> Breakpoint trap) and interrupts are kept masked while recursion/single
> stepping. Is it unsafe only if conflict with hardware breakpoint on
> same CPU?
Is this recursion only to support setting kprobes on the kprobe
implementation? The problem is that the rest of the debug infrastructure is
not set up to deal with recursive exceptions, so allowing them can break
state machines maintained by code like hw_breakpoint.
> >
> > In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> > places a hardware breakpoint on an instruction in the kernel for which
> > kprobes has patched in a brk. We take the hardware breakpoint, disable the
> > breakpoint and set up a single step before returning to the brk. The brk
> > then traps, but we must take care not to disable single-step and/or unmask
> > debug exceptions, because that will cause the hardware breakpoint code to
> > re-arm its breakpoint before we've stepped off the brk instruction.
> Not sure if kprobes can work together with hardware breakpoint or kgdb
> when multiple breakpoints (h/w and s/w) are placed on same text
> address. How arm32 and x86 handle this kind of scenario?
ARM doesn't support kernel hw breakpoints due to various limitations (we
don't have hw single step in ARMv7).
> Probably, the person debugging hardware breakpoint or kgdb should have
> control over the flow and disable kprobes (sysfs interface available)?
That sounds like a bit of a cop-out. I'd rather we understand the situation
and, if necessary, add code so that we can deny use of kprobes if kgdb is
active (or something similar) if we can't get the subsystems to collaborate.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-11 11:21 ` Will Deacon
@ 2013-11-12 6:52 ` Sandeepa Prabhu
2013-11-15 16:37 ` Will Deacon
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-12 6:52 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On 11 November 2013 16:51, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Nov 11, 2013 at 05:35:37AM +0000, Sandeepa Prabhu wrote:
>> On 8 November 2013 22:26, Will Deacon <will.deacon@arm.com> wrote:
>> >> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>> >> new file mode 100644
>> >> index 0000000..9b491d0
>> >> --- /dev/null
>> >> +++ b/arch/arm64/include/asm/kprobes.h
>> >> @@ -0,0 +1,59 @@
>> >> +/*
>> >> + * arch/arm64/include/asm/kprobes.h
>> >> + *
>> >> + * Copyright (C) 2013 Linaro Limited
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or modify
>> >> + * it under the terms of the GNU General Public License version 2 as
>> >> + * published by the Free Software Foundation.
>> >> + *
>> >> + * This program is distributed in the hope that it will be useful,
>> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> >> + * General Public License for more details.
>> >> + */
>> >> +
>> >> +#ifndef _ARM_KPROBES_H
>> >> +#define _ARM_KPROBES_H
>> >> +
>> >> +#include <linux/types.h>
>> >> +#include <linux/ptrace.h>
>> >> +#include <linux/percpu.h>
>> >> +
>> >> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>> >> +#define MAX_INSN_SIZE 2
>> >
>> > Why is this 2?
>> Second entry is to hold NOP instruction, absence of it cause abort
>> while instruction decode.
>
> Hmm, can you elaborate please? I'm not sure why you should get an abort
> decoding kernel addresses.
well, kprobes does not step from kernel address, but it prepares a
allocated memory(executable), copies the instruction and update the
single step address (ELR) to enable stepping while ERET.
So, don't we need NOP at next location after the instruction because
next instruction will be in decode stage and might throw "undefined
instruction" error?
I have removed the trailing NOP and tested single step and it worked
fine!, so I am not sure if MAX_INSN_SIZE can be 1, I would check v8
debug spec again.
>
>> >> +DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>> >> +DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> >> +
>> >> +static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> >> +{
>> >> + int i;
>> >> + /* prepare insn slot */
>> >> + p->ainsn.insn[0] = p->opcode;
>> >> + /* NOP for superscalar uArch decode */
>> >
>> > superscalar uArch?
>> well, the comment needs refining, what we mean is that one NOP should
>> follow the instruction in memory slot, for the decode stage(not to hit
>> undefined instruction).
>
> Is this undef related to your comment above?
[Yes, again, I don't know if trailing NOP is necessary as step is
working without it -decode stage for next location is not throwing
"undefined instruction" error while single stepping previous
instruction]
>
>> > NAK. Unmasking debug exceptions from within a debug exception is not safe.
>> > I'd much rather we returned from handling this exception, then took whatever
>> > other pending exception there was.
>> well, kprobes needs recursive breakpoints to be handled, and I am not
>> sure if this can be achieved other way than unmasking D-flag for a
>> shorter duration where we can expect re-entry (I would check if this
>> can be done without re-cursing)
>> I want to understand why unmasking D-flag is unsafe here, kprobes make
>> sure that recursion depth is only 2 (i.e. does not generate 3rd
>> Breakpoint trap) and interrupts are kept masked while recursion/single
>> stepping. Is it unsafe only if conflict with hardware breakpoint on
>> same CPU?
>
> Is this recursion only to support setting kprobes on the kprobe
> implementation? The problem is that the rest of the debug infrastructure is
> not set up to deal with recursive exceptions, so allowing them can break
> state machines maintained by code like hw_breakpoint.
No, upon one kprobe hit for an address, the subsystem can call the
user-defined handlers (pre- and -post) which can call same function
again. Example, if we place kprobe on "printk" entry, and registered
handler can invoke printk to print more info.
This will make kprobe to trigger again and re-enter, so the kprobe
subsystem need to handle the 2nd instance first, and then return back
to previous execution. D-flag is enabled only the duration when the
pre- and post- handler are called, so they they can recurse and handle
single stepping, after that, D-flag is kept disabled. I am yet to
test the concurrency with hw_breakpoint, would update once I run these
tests.
>
>> >
>> > In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>> > places a hardware breakpoint on an instruction in the kernel for which
>> > kprobes has patched in a brk. We take the hardware breakpoint, disable the
>> > breakpoint and set up a single step before returning to the brk. The brk
>> > then traps, but we must take care not to disable single-step and/or unmask
>> > debug exceptions, because that will cause the hardware breakpoint code to
>> > re-arm its breakpoint before we've stepped off the brk instruction.
>> Not sure if kprobes can work together with hardware breakpoint or kgdb
>> when multiple breakpoints (h/w and s/w) are placed on same text
>> address. How arm32 and x86 handle this kind of scenario?
>
> ARM doesn't support kernel hw breakpoints due to various limitations (we
> don't have hw single step in ARMv7).
>
>> Probably, the person debugging hardware breakpoint or kgdb should have
>> control over the flow and disable kprobes (sysfs interface available)?
>
> That sounds like a bit of a cop-out. I'd rather we understand the situation
> and, if necessary, add code so that we can deny use of kprobes if kgdb is
> active (or something similar) if we can't get the subsystems to collaborate.
Hmm, as it seems from x86 (updates from Masami), guessing it is fair
expectation that kprobes can co-exist with hardware breakpoints and
work even when happened to be both placed on same text address.
Though we have not discussed about *policy", I think as long as this
can be fixed, we should support it.
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-12 6:52 ` Sandeepa Prabhu
@ 2013-11-15 16:37 ` Will Deacon
2013-11-18 6:43 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-15 16:37 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On Tue, Nov 12, 2013 at 06:52:51AM +0000, Sandeepa Prabhu wrote:
> On 11 November 2013 16:51, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Nov 11, 2013 at 05:35:37AM +0000, Sandeepa Prabhu wrote:
> >> On 8 November 2013 22:26, Will Deacon <will.deacon@arm.com> wrote:
> >> >> +#define MAX_INSN_SIZE 2
> >> >
> >> > Why is this 2?
> >> Second entry is to hold NOP instruction, absence of it cause abort
> >> while instruction decode.
> >
> > Hmm, can you elaborate please? I'm not sure why you should get an abort
> > decoding kernel addresses.
> well, kprobes does not step from kernel address, but it prepares a
> allocated memory(executable), copies the instruction and update the
> single step address (ELR) to enable stepping while ERET.
> So, don't we need NOP at next location after the instruction because
> next instruction will be in decode stage and might throw "undefined
> instruction" error?
You can't take speculative prefetch aborts like that, so unless you actually
go and *execute* garbage, you don't need that NOP. From the sounds of it, it's
not required, as long as you handle the step exception correctly.
> >> > NAK. Unmasking debug exceptions from within a debug exception is not safe.
> >> > I'd much rather we returned from handling this exception, then took whatever
> >> > other pending exception there was.
> >> well, kprobes needs recursive breakpoints to be handled, and I am not
> >> sure if this can be achieved other way than unmasking D-flag for a
> >> shorter duration where we can expect re-entry (I would check if this
> >> can be done without re-cursing)
> >> I want to understand why unmasking D-flag is unsafe here, kprobes make
> >> sure that recursion depth is only 2 (i.e. does not generate 3rd
> >> Breakpoint trap) and interrupts are kept masked while recursion/single
> >> stepping. Is it unsafe only if conflict with hardware breakpoint on
> >> same CPU?
> >
> > Is this recursion only to support setting kprobes on the kprobe
> > implementation? The problem is that the rest of the debug infrastructure is
> > not set up to deal with recursive exceptions, so allowing them can break
> > state machines maintained by code like hw_breakpoint.
> No, upon one kprobe hit for an address, the subsystem can call the
> user-defined handlers (pre- and -post) which can call same function
> again. Example, if we place kprobe on "printk" entry, and registered
> handler can invoke printk to print more info.
Hang on, I think I'm missing something here. If you run into a recursive
probe, you'll simply hit another BRK instruction, right? That should be
fine, since PSTATE.D doesn't mask software breakpoint exceptions. The
tricky part comes when you try to step over that guy, but you might be ok
if you clear PSTATE.D *only* while you step your single instruction that you
copied out to the buffer.
What do you think? I'd really like you to try testing something like:
1. Place a hardware breakpoint in the kernel
2. Place a kprobe on the same address
3. Place a kprobe somewhere in the pre- hook for the kprobe placed in (2)
then check that (a) we manage to get through that lot without locking up and
(b) each probe/breakpoint is hit exactly once.
> This will make kprobe to trigger again and re-enter, so the kprobe
> subsystem need to handle the 2nd instance first, and then return back
> to previous execution. D-flag is enabled only the duration when the
> pre- and post- handler are called, so they they can recurse and handle
> single stepping, after that, D-flag is kept disabled. I am yet to
> test the concurrency with hw_breakpoint, would update once I run these
> tests.
If you really want to support this, you need to do more than just clear the
D flag. Not only do you need to deal with hardware breakpoints, but also
things like scheduling... Assuming that the user-defined handlers can block,
then you run the risk of context-switching with the D-flag set, which
introduces a significant black-out period to kernel debugging. There are
also issues like returning to userspace with MDSCR_EL1.SS set because of a
context switch triggered by the pre- handler, resulting in a single-step
exception from userspace.
I reckon what I suggested above might work, but I'd like your input.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
2013-11-15 16:37 ` Will Deacon
@ 2013-11-18 6:43 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-18 6:43 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On 15 November 2013 22:07, Will Deacon <will.deacon@arm.com> wrote:
>> well, kprobes does not step from kernel address, but it prepares a
>> allocated memory(executable), copies the instruction and update the
>> single step address (ELR) to enable stepping while ERET.
>> So, don't we need NOP at next location after the instruction because
>> next instruction will be in decode stage and might throw "undefined
>> instruction" error?
>
> You can't take speculative prefetch aborts like that, so unless you actually
> go and *execute* garbage, you don't need that NOP. From the sounds of it, it's
> not required, as long as you handle the step exception correctly.
Ok, the stepping is for exactly one instruction, after trapping again
stepping is disabled.
so clear that NOP is not necessary. I will remove NOP in next version.
>> > Is this recursion only to support setting kprobes on the kprobe
>> > implementation? The problem is that the rest of the debug infrastructure is
>> > not set up to deal with recursive exceptions, so allowing them can break
>> > state machines maintained by code like hw_breakpoint.
>> No, upon one kprobe hit for an address, the subsystem can call the
>> user-defined handlers (pre- and -post) which can call same function
>> again. Example, if we place kprobe on "printk" entry, and registered
>> handler can invoke printk to print more info.
>
> Hang on, I think I'm missing something here. If you run into a recursive
> probe, you'll simply hit another BRK instruction, right? That should be
> fine, since PSTATE.D doesn't mask software breakpoint exceptions. The
> tricky part comes when you try to step over that guy, but you might be ok
> if you clear PSTATE.D *only* while you step your single instruction that you
> copied out to the buffer.
Yes exactly, D-flag was enabled so that single step can run on BRK
handler code! exactly once. So I was unmasking D-flag before
taking(expecting) a BRK so that saved spsr_el1 in pt_regs have it
stored and restore when return with single stepping!
I agree with your suggestion to unmask D-flag just before ERET for
stepping, makes more sense, is it as simple as updating pt_regs
(regs->pstate)?
>
> What do you think? I'd really like you to try testing something like:
>
> 1. Place a hardware breakpoint in the kernel
> 2. Place a kprobe on the same address
> 3. Place a kprobe somewhere in the pre- hook for the kprobe placed in (2)
>
> then check that (a) we manage to get through that lot without locking up and
> (b) each probe/breakpoint is hit exactly once.
Ok, will do, this can be easily done with kprobing "printk" with pre-
handler invoking printk, and then placing a hw_breakpoint. (also we
need to check for kprobe-watchpoint concurrency right?)
I would update with results.
>
>> This will make kprobe to trigger again and re-enter, so the kprobe
>> subsystem need to handle the 2nd instance first, and then return back
>> to previous execution. D-flag is enabled only the duration when the
>> pre- and post- handler are called, so they they can recurse and handle
>> single stepping, after that, D-flag is kept disabled. I am yet to
>> test the concurrency with hw_breakpoint, would update once I run these
>> tests.
>
> If you really want to support this, you need to do more than just clear the
> D flag. Not only do you need to deal with hardware breakpoints, but also
> things like scheduling... Assuming that the user-defined handlers can block,
> then you run the risk of context-switching with the D-flag set, which
> introduces a significant black-out period to kernel debugging. There are
> also issues like returning to userspace with MDSCR_EL1.SS set because of a
> context switch triggered by the pre- handler, resulting in a single-step
> exception from userspace.
kprobe user-defined handlers should not block no blocking calls) and
this is one of the requirements of kprobes, so we cannot manage
context-switching or interrupts until the kprobe trap is completely
handled. So, we basically disable local interrupts throughout
exception handler.
Masami,
kprobe framework cannot check if the supplied user-handlers can block
right? and blocking call would cause undesired sequences, how to
handle this? (recommendations/policies?)
>
> I reckon what I suggested above might work, but I'd like your input.
Sure, would come back with more clear picture after running all tests
and making the changes as per your suggestion.
Thanks for reviewing this in detail,
-Sandeepa
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH RFC 3/6] arm64: Kprobes instruction simulation support
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 2/6] arm64: Kprobes with single stepping support Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 17:03 ` Will Deacon
2013-10-17 11:17 ` [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes) Sandeepa Prabhu
` (3 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
Add support for AArch64 instruction simulation in kprobes.
Kprobes need simulation of instructions that cannot be stepped
right-away from different memory location. i.e. those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using copy of pt_regs.
Following instruction catagories are simulated:
- All branching instructions(conditional, register, and immediate)
- Literal access instructions(load-literal, adr/adrp)
conditional execution are limited to branching instructions in
ARM v8. If conditions at PSTATE does not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes consider
this case as 'miss'.
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
---
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/condn-helpers.c | 120 +++++++++++++++++++++++++
arch/arm64/kernel/kprobes-arm64.c | 120 +++++++++++++++++++++++--
arch/arm64/kernel/kprobes-arm64.h | 2 +
arch/arm64/kernel/kprobes.c | 31 ++++++-
arch/arm64/kernel/simulate-insn.c | 184 ++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/simulate-insn.h | 33 +++++++
7 files changed, 480 insertions(+), 13 deletions(-)
create mode 100644 arch/arm64/kernel/condn-helpers.c
create mode 100644 arch/arm64/kernel/simulate-insn.c
create mode 100644 arch/arm64/kernel/simulate-insn.h
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 12ef8d2..b000a51 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -19,7 +19,8 @@ arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
-arm64-obj-$(CONFIG_KPROBES) += kprobes.o kprobes-arm64.o
+arm64-obj-$(CONFIG_KPROBES) += kprobes.o kprobes-arm64.o \
+ simulate-insn.o condn-helpers.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/condn-helpers.c b/arch/arm64/kernel/condn-helpers.c
new file mode 100644
index 0000000..7abc7ec
--- /dev/null
+++ b/arch/arm64/kernel/condn-helpers.c
@@ -0,0 +1,120 @@
+/*
+ * arch/arm64/kernel/condn-helpers.c
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * Copied from: arch/arm/kernel/kprobes-common.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * Description:
+ *
+ * AArch64 and AArch32 shares same conditional(CNZV) flags encoding.
+ * This file implements conditional check helpers compatible with
+ * both AArch64 and AArch32 modes. Uprobes on v8 can handle both 32-bit
+ * & 64-bit user-space instructions, so we abstract the common functions
+ * in this file. While AArch64 and AArch32 specific instruction handling
+ * are implemented in seperate files, this file contains common bits.
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <asm/probes.h>
+
+static unsigned long __kprobes __check_eq(unsigned long pstate)
+{
+ return pstate & PSR_Z_BIT;
+}
+
+static unsigned long __kprobes __check_ne(unsigned long pstate)
+{
+ return (~pstate) & PSR_Z_BIT;
+}
+
+static unsigned long __kprobes __check_cs(unsigned long pstate)
+{
+ return pstate & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_cc(unsigned long pstate)
+{
+ return (~pstate) & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_mi(unsigned long pstate)
+{
+ return pstate & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_pl(unsigned long pstate)
+{
+ return (~pstate) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_vs(unsigned long pstate)
+{
+ return pstate & PSR_V_BIT;
+}
+
+static unsigned long __kprobes __check_vc(unsigned long pstate)
+{
+ return (~pstate) & PSR_V_BIT;
+}
+
+static unsigned long __kprobes __check_hi(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return pstate & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_ls(unsigned long pstate)
+{
+ pstate &= ~(pstate >> 1); /* PSR_C_BIT &= ~PSR_Z_BIT */
+ return (~pstate) & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_ge(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return (~pstate) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_lt(unsigned long pstate)
+{
+ pstate ^= (pstate << 3); /* PSR_N_BIT ^= PSR_V_BIT */
+ return pstate & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_gt(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return (~temp) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_le(unsigned long pstate)
+{
+ /*PSR_N_BIT ^= PSR_V_BIT */
+ unsigned long temp = pstate ^ (pstate << 3);
+ temp |= (pstate << 1); /*PSR_N_BIT |= PSR_Z_BIT */
+ return temp & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_al(unsigned long pstate)
+{
+ return true;
+}
+
+kprobes_pstate_check_t * const kprobe_condition_checks[16] = {
+ &__check_eq, &__check_ne, &__check_cs, &__check_cc,
+ &__check_mi, &__check_pl, &__check_vs, &__check_vc,
+ &__check_hi, &__check_ls, &__check_ge, &__check_lt,
+ &__check_gt, &__check_le, &__check_al, &__check_al
+};
diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
index 30d1c14..c690be3 100644
--- a/arch/arm64/kernel/kprobes-arm64.c
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -20,6 +20,101 @@
#include "probes-decode.h"
#include "kprobes-arm64.h"
+#include "simulate-insn.h"
+
+/*
+ * condition check functions for kprobes simulation
+ */
+static unsigned long __kprobes
+__check_pstate(struct kprobe *p, struct pt_regs *regs)
+{
+ struct arch_specific_insn *asi = &p->ainsn;
+ unsigned long pstate = regs->pstate & 0xffffffff;
+
+ return asi->pstate_cc(pstate);
+}
+
+static unsigned long __kprobes
+__check_cbz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_cbz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_cbnz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_cbnz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_tbz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbnz(struct kprobe *p, struct pt_regs *regs)
+{
+ return check_tbnz((u32)p->opcode, regs);
+}
+
+/*
+ * prepare functions for instruction simulation
+ */
+static void __kprobes
+prepare_none(struct kprobe *p, struct arch_specific_insn *asi)
+{
+}
+
+static void __kprobes
+prepare_bcond(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p->opcode;
+
+ asi->check_condn = __check_pstate;
+ asi->pstate_cc = kprobe_condition_checks[insn & 0xf];
+}
+
+static void __kprobes
+prepare_cbz_cbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p->opcode;
+
+ asi->check_condn = (insn & (1 << 24)) ? __check_cbnz : __check_cbz;
+}
+
+static void __kprobes
+prepare_tbz_tbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+ kprobe_opcode_t insn = p->opcode;
+
+ asi->check_condn = (insn & (1 << 24)) ? __check_tbnz : __check_tbz;
+}
+
+
+/* Load literal (PC-relative) instructions
+ * Encoding: xx01 1x00 xxxx xxxx xxxx xxxx xxxx xxxx
+ *
+ * opcode[26]: V=0, Load GP registers, simulate them.
+ * Encoding: xx01 1000 xxxx xxxx xxxx xxxx xxxx xxxx
+ * opcode[31:30]: op = 00, 01 - LDR literal
+ * opcode[31:30]: op = 10, - LDRSW literal
+ *
+ * 1. V=1 -Load FP/AdvSIMD registers
+ * Encoding: xx01 1100 xxxx xxxx xxxx xxxx xxxx xxxx
+ * 2. V=0,opc=11 -PRFM(Prefetch literal)
+ * Encoding: 1101 1000 xxxx xxxx xxxx xxxx xxxx xxxx
+ * Reject FP/AdvSIMD literal load & PRFM literal.
+ */
+static const struct aarch64_decode_item load_literal_subtable[] = {
+ DECODE_REJECT(0x1C000000, 0x3F000000),
+ DECODE_REJECT(0xD8000000, 0xFF000000),
+ DECODE_LITERAL(0x18000000, 0xBF000000, prepare_none,
+ simulate_ldr_literal),
+ DECODE_LITERAL(0x98000000, 0xFF000000, prepare_none,
+ simulate_ldrsw_literal),
+ DECODE_END,
+};
/* AArch64 instruction decode table for kprobes:
* The instruction will fall into one of the 3 groups:
@@ -43,7 +138,8 @@ static const struct aarch64_decode_item aarch64_decode_table[] = {
* Data processing - PC relative(literal) addressing:
* Encoding: xxx1 0000 xxxx xxxx xxxx xxxx xxxx xxxx
*/
- DECODE_REJECT(0x10000000, 0x1F000000),
+ DECODE_LITERAL(0x10000000, 0x1F000000, prepare_none,
+ simulate_adr_adrp),
/*
* Data processing - Add/Substract Immediate:
@@ -83,12 +179,16 @@ static const struct aarch64_decode_item aarch64_decode_table[] = {
* 0101 010x xxxx xxxx xxxx xxxx xxxx xxxx (Conditional, immediate)
* 1101 011x xxxx xxxx xxxx xxxx xxxx xxxx (Unconditional,register)
*/
- DECODE_REJECT(0x14000000, 0x7C000000),
- DECODE_REJECT(0x14000000, 0x7C000000),
- DECODE_REJECT(0x34000000, 0x7E000000),
- DECODE_REJECT(0x36000000, 0x7E000000),
- DECODE_REJECT(0x54000000, 0xFE000000),
- DECODE_REJECT(0xD6000000, 0xFE000000),
+ DECODE_BRANCH(0x14000000, 0x7C000000, prepare_none,
+ simulate_b_bl),
+ DECODE_BRANCH(0x34000000, 0x7E000000, prepare_cbz_cbnz,
+ simulate_cbz_cbnz),
+ DECODE_BRANCH(0x36000000, 0x7E000000, prepare_tbz_tbnz,
+ simulate_tbz_tbnz),
+ DECODE_BRANCH(0x54000000, 0xFE000000, prepare_bcond,
+ simulate_b_cond),
+ DECODE_BRANCH(0xD6000000, 0xFE000000, prepare_none,
+ simulate_br_blr_ret),
/* System insn:
* Encoding: 1101 0101 00xx xxxx xxxx xxxx xxxx xxxx
@@ -119,7 +219,7 @@ static const struct aarch64_decode_item aarch64_decode_table[] = {
* Load/Store - PC relative(literal):
* Encoding: xx01 1x00 xxxx xxxx xxxx xxxx xxxx xxxx
*/
- DECODE_REJECT(0x18000000, 0x3B000000),
+ DECODE_TABLE(0x18000000, 0x3B000000, load_literal_subtable),
/*
* Load/Store - Register Pair
@@ -188,7 +288,9 @@ kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
break;
case DECODE_TYPE_SIMULATE:
- ret = INSN_REJECTED;
+ asi->prepare = decode_prepare_fn(tbl[entry]);
+ asi->handler = decode_handler_fn(tbl[entry]);
+ ret = INSN_GOOD_NO_SLOT;
break;
case DECODE_TYPE_TABLE:
diff --git a/arch/arm64/kernel/kprobes-arm64.h b/arch/arm64/kernel/kprobes-arm64.h
index 87e7891..ff8a55f 100644
--- a/arch/arm64/kernel/kprobes-arm64.h
+++ b/arch/arm64/kernel/kprobes-arm64.h
@@ -22,6 +22,8 @@ enum kprobe_insn {
INSN_GOOD,
};
+extern kprobes_pstate_check_t * const kprobe_condition_checks[16];
+
enum kprobe_insn __kprobes
arm_kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi);
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index def10b6..1fa8690 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -37,6 +37,9 @@
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+static int __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs);
+
static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
{
int i;
@@ -50,6 +53,23 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
(uintptr_t) (p->ainsn.insn) + MAX_INSN_SIZE);
}
+static void __kprobes arch_prepare_simulate(struct kprobe *p)
+{
+ if (p->ainsn.prepare)
+ p->ainsn.prepare(p, &p->ainsn);
+}
+
+static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+ if (p->ainsn.handler)
+ p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
+
+ /* single step simulated, now go for post processing */
+ post_kprobe_handler(kcb, regs);
+}
+
int __kprobes arch_prepare_kprobe(struct kprobe *p)
{
kprobe_opcode_t insn;
@@ -69,7 +89,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
break;
case INSN_GOOD_NO_SLOT: /* insn need simulation */
- return -EINVAL;
+ p->ainsn.insn = NULL;
break;
case INSN_GOOD: /* instruction uses slot */
@@ -80,7 +100,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
};
/* prepare the instruction */
- arch_prepare_ss_slot(p);
+ if (p->ainsn.insn)
+ arch_prepare_ss_slot(p);
+ else
+ arch_prepare_simulate(p);
return 0;
}
@@ -199,13 +222,15 @@ static void __kprobes setup_singlestep(struct kprobe *p,
*/
p->ainsn.restore.addr = instruction_pointer(regs) +
sizeof(kprobe_opcode_t);
+
p->ainsn.restore.type = RESTORE_PC;
set_ss_context(kcb, slot); /* mark pending ss */
kernel_enable_single_step(regs);
instruction_pointer(regs) = slot;
} else {
- BUG();
+ /* insn simulation */
+ arch_simulate_insn(p, regs);
}
}
diff --git a/arch/arm64/kernel/simulate-insn.c b/arch/arm64/kernel/simulate-insn.c
new file mode 100644
index 0000000..10173cf
--- /dev/null
+++ b/arch/arm64/kernel/simulate-insn.c
@@ -0,0 +1,184 @@
+/*
+ * arch/arm64/kernel/simulate-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+
+#include "simulate-insn.h"
+
+#define sign_extend(x, signbit) \
+ ((x) | (0 - ((x) & (1 << (signbit)))))
+
+#define bbl_displacement(insn) \
+ sign_extend(((insn) & 0x3ffffff) << 2, 27)
+
+#define bcond_displacement(insn) \
+ sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
+
+#define cbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
+
+#define tbz_displacement(insn) \
+ sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
+
+#define ldr_displacement(insn) \
+ sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
+
+
+unsigned long __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ !(regs->regs[xn]) : !(regs->regs[xn] & 0xffffffff);
+}
+
+unsigned long __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+
+ return (opcode & (1 << 31)) ?
+ (regs->regs[xn]) : (regs->regs[xn] & 0xffffffff);
+}
+
+unsigned long __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return ~((regs->regs[xn] >> bit_pos) & 0x1);
+}
+
+unsigned long __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
+{
+ int xn = opcode & 0x1f;
+ int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+ return (regs->regs[xn] >> bit_pos) & 0x1;
+}
+
+/*
+ * instruction simulate functions
+ */
+void __kprobes simulate_none(u32 opcode, long addr, struct pt_regs *regs)
+{
+}
+
+void __kprobes
+simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
+{
+ long res, imm, xn;
+
+ xn = opcode & 0x1f;
+ imm = ((opcode >> 3) & 0xffffc) | ((opcode >> 29) & 0x3);
+ res = addr + 8 + sign_extend(imm, 20);
+
+ regs->regs[xn] = opcode & 0x80000000 ? res & 0xfffffffffffff000 : res;
+ instruction_pointer(regs) += 4;
+
+ return;
+}
+
+void __kprobes
+simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = bbl_displacement(opcode);
+
+ /* Link register is x30 */
+ if (opcode & (1 << 31))
+ regs->regs[30] = addr + 4;
+
+ instruction_pointer(regs) = addr + disp;
+
+ return;
+}
+
+void __kprobes
+simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = bcond_displacement(opcode);
+
+ instruction_pointer(regs) = addr + disp;
+
+ return;
+}
+
+void __kprobes
+simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int xn = (opcode >> 5) & 0x1f;
+
+ /* Link register is x30 */
+ if (((opcode >> 21) & 0x3) == 1)
+ regs->regs[30] = addr + 4;
+
+ instruction_pointer(regs) = regs->regs[xn];
+
+ return;
+}
+
+void __kprobes
+simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = cbz_displacement(opcode);
+
+ instruction_pointer(regs) = addr + disp;
+
+ return;
+}
+
+void __kprobes
+simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+ int disp = tbz_displacement(opcode);
+
+ instruction_pointer(regs) = addr + disp;
+
+ return;
+}
+
+void __kprobes
+simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ u64 *load_addr;
+ int xn = opcode & 0x1f;
+ int disp = ldr_displacement(opcode);
+
+ load_addr = (u64 *) (addr + disp);
+
+ if (opcode & (1 << 30)) /* x0-x31 */
+ regs->regs[xn] = *load_addr;
+ else /* w0-w31 */
+ *(u32 *) (®s->regs[xn]) = (*(u32 *) (load_addr));
+
+ return;
+}
+
+void __kprobes
+simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+ u64 *load_addr;
+ long data;
+ int xn = opcode & 0x1f;
+ int disp = ldr_displacement(opcode);
+
+ load_addr = (u64 *) (addr + disp);
+ data = *load_addr;
+
+ regs->regs[xn] = sign_extend(data, 63);
+
+ return;
+}
diff --git a/arch/arm64/kernel/simulate-insn.h b/arch/arm64/kernel/simulate-insn.h
new file mode 100644
index 0000000..7713bf6
--- /dev/null
+++ b/arch/arm64/kernel/simulate-insn.h
@@ -0,0 +1,33 @@
+/*
+ * arch/arm64/kernel/simulate-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _ARM_KERNEL_SIMULATE_INSN_H
+#define _ARM_KERNEL_SIMULATE_INSN_H
+
+unsigned long check_cbz(u32 opcode, struct pt_regs *regs);
+unsigned long check_cbnz(u32 opcode, struct pt_regs *regs);
+unsigned long check_tbz(u32 opcode, struct pt_regs *regs);
+unsigned long check_tbnz(u32 opcode, struct pt_regs *regs);
+void simulate_none(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
+
+#endif /* _ARM_KERNEL_SIMULATE_INSN_H */
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH RFC 3/6] arm64: Kprobes instruction simulation support
2013-10-17 11:17 ` [PATCH RFC 3/6] arm64: Kprobes instruction simulation support Sandeepa Prabhu
@ 2013-11-08 17:03 ` Will Deacon
2013-11-11 5:58 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-08 17:03 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On Thu, Oct 17, 2013 at 12:17:48PM +0100, Sandeepa Prabhu wrote:
> Add support for AArch64 instruction simulation in kprobes.
>
> Kprobes need simulation of instructions that cannot be stepped
> right-away from different memory location. i.e. those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using copy of pt_regs.
>
> Following instruction catagories are simulated:
> - All branching instructions(conditional, register, and immediate)
> - Literal access instructions(load-literal, adr/adrp)
>
> conditional execution are limited to branching instructions in
> ARM v8. If conditions at PSTATE does not match the condition fields
> of opcode, the instruction is effectively NOP. Kprobes consider
> this case as 'miss'.
[...]
> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
> index 30d1c14..c690be3 100644
> --- a/arch/arm64/kernel/kprobes-arm64.c
> +++ b/arch/arm64/kernel/kprobes-arm64.c
> @@ -20,6 +20,101 @@
>
> #include "probes-decode.h"
> #include "kprobes-arm64.h"
> +#include "simulate-insn.h"
> +
> +/*
> + * condition check functions for kprobes simulation
> + */
> +static unsigned long __kprobes
> +__check_pstate(struct kprobe *p, struct pt_regs *regs)
> +{
> + struct arch_specific_insn *asi = &p->ainsn;
> + unsigned long pstate = regs->pstate & 0xffffffff;
> +
> + return asi->pstate_cc(pstate);
> +}
> +
> +static unsigned long __kprobes
> +__check_cbz(struct kprobe *p, struct pt_regs *regs)
> +{
> + return check_cbz((u32)p->opcode, regs);
Isn't p->opcode already a u32? (by your definition of kprobe_opcode_t).
> diff --git a/arch/arm64/kernel/simulate-insn.c b/arch/arm64/kernel/simulate-insn.c
> new file mode 100644
> index 0000000..10173cf
> --- /dev/null
> +++ b/arch/arm64/kernel/simulate-insn.c
> @@ -0,0 +1,184 @@
> +/*
> + * arch/arm64/kernel/simulate-insn.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +
> +#include "simulate-insn.h"
> +
> +#define sign_extend(x, signbit) \
> + ((x) | (0 - ((x) & (1 << (signbit)))))
> +
> +#define bbl_displacement(insn) \
> + sign_extend(((insn) & 0x3ffffff) << 2, 27)
> +
> +#define bcond_displacement(insn) \
> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
> +
> +#define cbz_displacement(insn) \
> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
> +
> +#define tbz_displacement(insn) \
> + sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
> +
> +#define ldr_displacement(insn) \
> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
The mask, shift and signbit position are all related here, so you could
rework the definition of sign_extend to avoid having three magic numbers.
Will
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 3/6] arm64: Kprobes instruction simulation support
2013-11-08 17:03 ` Will Deacon
@ 2013-11-11 5:58 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-11 5:58 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, Vijaya.Kumar, Jiang Liu
On 8 November 2013 22:33, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Oct 17, 2013 at 12:17:48PM +0100, Sandeepa Prabhu wrote:
>> Add support for AArch64 instruction simulation in kprobes.
>>
>> Kprobes need simulation of instructions that cannot be stepped
>> right-away from different memory location. i.e. those instructions
>> that uses PC-relative addressing. In simulation, the behaviour
>> of the instruction is implemented using copy of pt_regs.
>>
>> Following instruction catagories are simulated:
>> - All branching instructions(conditional, register, and immediate)
>> - Literal access instructions(load-literal, adr/adrp)
>>
>> conditional execution are limited to branching instructions in
>> ARM v8. If conditions at PSTATE does not match the condition fields
>> of opcode, the instruction is effectively NOP. Kprobes consider
>> this case as 'miss'.
>
> [...]
>
>> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
>> index 30d1c14..c690be3 100644
>> --- a/arch/arm64/kernel/kprobes-arm64.c
>> +++ b/arch/arm64/kernel/kprobes-arm64.c
>> @@ -20,6 +20,101 @@
>>
>> #include "probes-decode.h"
>> #include "kprobes-arm64.h"
>> +#include "simulate-insn.h"
>> +
>> +/*
>> + * condition check functions for kprobes simulation
>> + */
>> +static unsigned long __kprobes
>> +__check_pstate(struct kprobe *p, struct pt_regs *regs)
>> +{
>> + struct arch_specific_insn *asi = &p->ainsn;
>> + unsigned long pstate = regs->pstate & 0xffffffff;
>> +
>> + return asi->pstate_cc(pstate);
>> +}
>> +
>> +static unsigned long __kprobes
>> +__check_cbz(struct kprobe *p, struct pt_regs *regs)
>> +{
>> + return check_cbz((u32)p->opcode, regs);
>
> Isn't p->opcode already a u32? (by your definition of kprobe_opcode_t).
Yup, can avoid typecasting.
>
>> diff --git a/arch/arm64/kernel/simulate-insn.c b/arch/arm64/kernel/simulate-insn.c
>> new file mode 100644
>> index 0000000..10173cf
>> --- /dev/null
>> +++ b/arch/arm64/kernel/simulate-insn.c
>> @@ -0,0 +1,184 @@
>> +/*
>> + * arch/arm64/kernel/simulate-insn.c
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +
>> +#include "simulate-insn.h"
>> +
>> +#define sign_extend(x, signbit) \
>> + ((x) | (0 - ((x) & (1 << (signbit)))))
>> +
>> +#define bbl_displacement(insn) \
>> + sign_extend(((insn) & 0x3ffffff) << 2, 27)
>> +
>> +#define bcond_displacement(insn) \
>> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
>> +
>> +#define cbz_displacement(insn) \
>> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
>> +
>> +#define tbz_displacement(insn) \
>> + sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
>> +
>> +#define ldr_displacement(insn) \
>> + sign_extend(((insn >> 5) & 0xfffff) << 2, 21)
>
> The mask, shift and signbit position are all related here, so you could
> rework the definition of sign_extend to avoid having three magic numbers.
Hmm, mask and signbit are related, shift is based on instruction type
(conditional instructions need >> 5 for extracting immediate offset).
I will refine these macros in next version.
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes)
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
` (2 preceding siblings ...)
2013-10-17 11:17 ` [PATCH RFC 3/6] arm64: Kprobes instruction simulation support Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 17:04 ` Will Deacon
2013-10-17 11:17 ` [PATCH RFC 5/6] arm64: Enable kprobes support for arm64 platform Sandeepa Prabhu
` (2 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
AArch64 ISA does not instructions to pop PC register value
from stack(like ARM v7 has ldmia {...,pc}) without using
one of the general purpose registers. This means return probes
cannot return to the actual return address directly without
modifying register context, and without trapping into debug exception.
So like many other architectures, we prepare a global routine
with NOPs, which serve as trampoline to hack away the
function return address, by placing an extra kprobe on the
trampoline entry.
The pre-handler of this special trampoline' kprobe execute return
probe handler functions and restore original return address in ELR_EL1,
this way, saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kprobes.h | 1 +
arch/arm64/include/asm/ptrace.h | 5 ++
arch/arm64/kernel/kprobes.c | 125 ++++++++++++++++++++++++++++++++++++++-
4 files changed, 129 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2e89059..73eff55 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -28,6 +28,7 @@ config ARM64
select HAVE_MEMBLOCK
select HAVE_PERF_EVENTS
select HAVE_KPROBES if !XIP_KERNEL
+ select HAVE_KRETPROBES if (HAVE_KPROBES)
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 9b491d0..eaca849 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -55,5 +55,6 @@ void arch_remove_kprobe(struct kprobe *);
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
+void kretprobe_trampoline(void);
#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 89f1727..58b2589 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -166,6 +166,11 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
#define instruction_pointer(regs) (regs)->pc
#define stack_pointer(regs) ((regs)->sp)
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs->regs[0];
+}
+
#ifdef CONFIG_SMP
extern unsigned long profile_pc(struct pt_regs *regs);
#else
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 1fa8690..0a6f31f 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -219,9 +219,16 @@ static void __kprobes setup_singlestep(struct kprobe *p,
/*
* Needs restoring of return address after stepping xol.
+ * If this happens to be a return probe, the exception
+ * return address would have been hacked by the pre_handler
+ * to point to trampoline, so we shall restore trampoline
+ * address after stepping. Other cases, it is just next pc.
*/
- p->ainsn.restore.addr = instruction_pointer(regs) +
- sizeof(kprobe_opcode_t);
+ if ((long)p->addr == instruction_pointer(regs))
+ p->ainsn.restore.addr = instruction_pointer(regs) +
+ sizeof(kprobe_opcode_t); /* next pc */
+ else /* hacked ret addr, could be kretprobe */
+ p->ainsn.restore.addr = regs->pc;
p->ainsn.restore.type = RESTORE_PC;
@@ -542,6 +549,117 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
return 0;
}
+/*
+ * Kretprobes: kernel return probes handling
+ *
+ * AArch64 mode does not support popping the PC value from the
+ * stack like on ARM 32-bit (ldmia {..,pc}), so atleast one
+ * register need to be used to achieve branching/return.
+ * It means return probes cannot return back to the original
+ * return address directly without modifying the register context.
+ *
+ * So like other architectures, we prepare a global routine
+ * with NOPs, which serve as trampoline address that hack away the
+ * function return, with the exact register context.
+ * Placing a kprobe on trampoline routine entry will trap again to
+ * execute return probe handlers and restore original return address
+ * in ELR_EL1, this way saved pt_regs still hold the original
+ * register values to be carried back to the caller.
+ */
+static void __used kretprobe_trampoline_holder(void)
+{
+ asm volatile (".global kretprobe_trampoline\n"
+ "kretprobe_trampoline:\n"
+ "NOP\n\t"
+ "NOP\n\t");
+}
+
+static int __kprobes
+trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
+{
+ struct kretprobe_instance *ri = NULL;
+ struct hlist_head *head, empty_rp;
+ struct hlist_node *tmp;
+ unsigned long flags, orig_ret_addr = 0;
+ unsigned long trampoline_address =
+ (unsigned long)&kretprobe_trampoline;
+
+ INIT_HLIST_HEAD(&empty_rp);
+ kretprobe_hash_lock(current, &head, &flags);
+
+ /*
+ * It is possible to have multiple instances associated with a given
+ * task either because multiple functions in the call path have
+ * a return probe installed on them, and/or more than one return
+ * probe was registered for a target function.
+ *
+ * We can handle this because:
+ * - instances are always inserted at the head of the list
+ * - when multiple return probes are registered for the same
+ * function, the first instance's ret_addr will point to the
+ * real return address, and all the rest will point to
+ * kretprobe_trampoline
+ */
+ hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+ if (ri->task != current)
+ /* another task is sharing our hash bucket */
+ continue;
+
+ if (ri->rp && ri->rp->handler) {
+ __get_cpu_var(current_kprobe) = &ri->rp->kp;
+ get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+ ri->rp->handler(ri, regs);
+ __get_cpu_var(current_kprobe) = NULL;
+ }
+
+ orig_ret_addr = (unsigned long)ri->ret_addr;
+ recycle_rp_inst(ri, &empty_rp);
+
+ if (orig_ret_addr != trampoline_address)
+ /*
+ * This is the real return address. Any other
+ * instances associated with this task are for
+ * other calls deeper on the call stack
+ */
+ break;
+ }
+
+ kretprobe_assert(ri, orig_ret_addr, trampoline_address);
+ /* restore the original return address */
+ instruction_pointer(regs) = orig_ret_addr;
+ reset_current_kprobe();
+ kretprobe_hash_unlock(current, &flags);
+ preempt_enable_no_resched();
+
+ hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
+ hlist_del(&ri->hlist);
+ kfree(ri);
+ }
+
+ /* return 1 so that post handlers not called */
+ return 1;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+ struct pt_regs *regs)
+{
+ ri->ret_addr = (kprobe_opcode_t *)
+ (instruction_pointer(regs) + sizeof(kprobe_opcode_t));
+
+ /* Replace the return addr with trampoline addr */
+ instruction_pointer(regs) = (unsigned long)&kretprobe_trampoline;
+}
+
+static struct kprobe trampoline = {
+ .addr = (kprobe_opcode_t *) &kretprobe_trampoline,
+ .pre_handler = trampoline_probe_handler
+};
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+ return p->addr == (kprobe_opcode_t *) &kretprobe_trampoline;
+}
+
/* Break Handler hook */
static struct break_hook kprobes_break_hook = {
.esr_mask = BRK64_ESR_MASK,
@@ -559,5 +677,6 @@ int __init arch_init_kprobes()
register_break_hook(&kprobes_break_hook);
register_step_hook(&kprobes_step_hook);
- return 0;
+ /* register trampoline for kret probe */
+ return register_kprobe(&trampoline);
}
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes)
2013-10-17 11:17 ` [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes) Sandeepa Prabhu
@ 2013-11-08 17:04 ` Will Deacon
2013-11-11 4:29 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-11-08 17:04 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On Thu, Oct 17, 2013 at 12:17:49PM +0100, Sandeepa Prabhu wrote:
> AArch64 ISA does not instructions to pop PC register value
> from stack(like ARM v7 has ldmia {...,pc}) without using
> one of the general purpose registers. This means return probes
> cannot return to the actual return address directly without
> modifying register context, and without trapping into debug exception.
>
> So like many other architectures, we prepare a global routine
> with NOPs, which serve as trampoline to hack away the
> function return address, by placing an extra kprobe on the
> trampoline entry.
>
> The pre-handler of this special trampoline' kprobe execute return
> probe handler functions and restore original return address in ELR_EL1,
> this way, saved pt_regs still hold the original register context to be
> carried back to the probed kernel function.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/kprobes.h | 1 +
> arch/arm64/include/asm/ptrace.h | 5 ++
> arch/arm64/kernel/kprobes.c | 125 ++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 129 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 2e89059..73eff55 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -28,6 +28,7 @@ config ARM64
> select HAVE_MEMBLOCK
> select HAVE_PERF_EVENTS
> select HAVE_KPROBES if !XIP_KERNEL
> + select HAVE_KRETPROBES if (HAVE_KPROBES)
Don't need the brackets.
> select IRQ_DOMAIN
> select MODULES_USE_ELF_RELA
> select NO_BOOTMEM
> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
> index 9b491d0..eaca849 100644
> --- a/arch/arm64/include/asm/kprobes.h
> +++ b/arch/arm64/include/asm/kprobes.h
> @@ -55,5 +55,6 @@ void arch_remove_kprobe(struct kprobe *);
> int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
> int kprobe_exceptions_notify(struct notifier_block *self,
> unsigned long val, void *data);
> +void kretprobe_trampoline(void);
>
> #endif /* _ARM_KPROBES_H */
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index 89f1727..58b2589 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -166,6 +166,11 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
> #define instruction_pointer(regs) (regs)->pc
> #define stack_pointer(regs) ((regs)->sp)
>
> +static inline long regs_return_value(struct pt_regs *regs)
> +{
> + return regs->regs[0];
> +}
This is also being implemented by another patch series (I think the audit
stuff?).
Will
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes)
2013-11-08 17:04 ` Will Deacon
@ 2013-11-11 4:29 ` Sandeepa Prabhu
2013-11-11 7:53 ` AKASHI Takahiro
0 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-11 4:29 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On 8 November 2013 22:34, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Oct 17, 2013 at 12:17:49PM +0100, Sandeepa Prabhu wrote:
>> AArch64 ISA does not instructions to pop PC register value
>> from stack(like ARM v7 has ldmia {...,pc}) without using
>> one of the general purpose registers. This means return probes
>> cannot return to the actual return address directly without
>> modifying register context, and without trapping into debug exception.
>>
>> So like many other architectures, we prepare a global routine
>> with NOPs, which serve as trampoline to hack away the
>> function return address, by placing an extra kprobe on the
>> trampoline entry.
>>
>> The pre-handler of this special trampoline' kprobe execute return
>> probe handler functions and restore original return address in ELR_EL1,
>> this way, saved pt_regs still hold the original register context to be
>> carried back to the probed kernel function.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/kprobes.h | 1 +
>> arch/arm64/include/asm/ptrace.h | 5 ++
>> arch/arm64/kernel/kprobes.c | 125 ++++++++++++++++++++++++++++++++++++++-
>> 4 files changed, 129 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 2e89059..73eff55 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -28,6 +28,7 @@ config ARM64
>> select HAVE_MEMBLOCK
>> select HAVE_PERF_EVENTS
>> select HAVE_KPROBES if !XIP_KERNEL
>> + select HAVE_KRETPROBES if (HAVE_KPROBES)
>
> Don't need the brackets.
OK.
>
>> select IRQ_DOMAIN
>> select MODULES_USE_ELF_RELA
>> select NO_BOOTMEM
>> diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
>> index 9b491d0..eaca849 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -55,5 +55,6 @@ void arch_remove_kprobe(struct kprobe *);
>> int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
>> int kprobe_exceptions_notify(struct notifier_block *self,
>> unsigned long val, void *data);
>> +void kretprobe_trampoline(void);
>>
>> #endif /* _ARM_KPROBES_H */
>> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
>> index 89f1727..58b2589 100644
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -166,6 +166,11 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
>> #define instruction_pointer(regs) (regs)->pc
>> #define stack_pointer(regs) ((regs)->sp)
>>
>> +static inline long regs_return_value(struct pt_regs *regs)
>> +{
>> + return regs->regs[0];
>> +}
>
> This is also being implemented by another patch series (I think the audit
> stuff?).
Not sure, I did not see this being implemented in audit(audit adds for
'syscallno', not for return value in x0)
I can rebase my code if this change is implemented and queued in other patchset.
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes)
2013-11-11 4:29 ` Sandeepa Prabhu
@ 2013-11-11 7:53 ` AKASHI Takahiro
2013-11-11 8:55 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: AKASHI Takahiro @ 2013-11-11 7:53 UTC (permalink / raw)
To: Sandeepa Prabhu, Will Deacon
Cc: linaro-kernel, steve.capper, srikar, patches, Catalin Marinas,
Vijaya.Kumar, nico, linux-kernel, rostedt, dsaxena,
masami.hiramatsu.pt, linux-arm-kernel, jiang.liu
On 11/11/2013 01:29 PM, Sandeepa Prabhu wrote:
> On 8 November 2013 22:34, Will Deacon <will.deacon@arm.com> wrote:
>>> +static inline long regs_return_value(struct pt_regs *regs)
>>> +{
>>> + return regs->regs[0];
>>> +}
>>
>> This is also being implemented by another patch series (I think the audit
>> stuff?).
> Not sure, I did not see this being implemented in audit(audit adds for
> 'syscallno', not for return value in x0)
> I can rebase my code if this change is implemented and queued in other patchset.
Yes, my audit patch has it.
The definition is referred to in include/linux/audit.h (and ptrace.h),
too.
-Takahiro AKASHI
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes)
2013-11-11 7:53 ` AKASHI Takahiro
@ 2013-11-11 8:55 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-11 8:55 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: Will Deacon, linaro-kernel, steve.capper, srikar, patches,
Catalin Marinas, Vijaya.Kumar, nico, linux-kernel, rostedt,
dsaxena, masami.hiramatsu.pt, linux-arm-kernel, jiang.liu
On 11 November 2013 13:23, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> On 11/11/2013 01:29 PM, Sandeepa Prabhu wrote:
>>
>> On 8 November 2013 22:34, Will Deacon <will.deacon@arm.com> wrote:
>>>>
>>>> +static inline long regs_return_value(struct pt_regs *regs)
>>>> +{
>>>> + return regs->regs[0];
>>>> +}
>>>
>>>
>>> This is also being implemented by another patch series (I think the audit
>>> stuff?).
>>
>> Not sure, I did not see this being implemented in audit(audit adds for
>> 'syscallno', not for return value in x0)
>> I can rebase my code if this change is implemented and queued in other
>> patchset.
>
>
> Yes, my audit patch has it.
> The definition is referred to in include/linux/audit.h (and ptrace.h),
> too.
Thanks, I will rebase kprobes code to use your API.
>
> -Takahiro AKASHI
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH RFC 5/6] arm64: Enable kprobes support for arm64 platform
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
` (3 preceding siblings ...)
2013-10-17 11:17 ` [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes) Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module Sandeepa Prabhu
2013-10-18 8:32 ` [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Masami Hiramatsu
6 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
This patch enables kprobes support in arm64 common defconfig
file.
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
---
arch/arm64/configs/defconfig | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 31c81e9..105f37c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1,12 +1,11 @@
-CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
@@ -19,6 +18,7 @@ CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_COMPAT_BRK is not set
CONFIG_PROFILING=y
+CONFIG_KPROBES=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
@@ -42,13 +42,12 @@ CONFIG_IP_PNP_BOOTP=y
# CONFIG_WIRELESS is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
-CONFIG_BLK_DEV=y
+CONFIG_VIRTIO_BLK=y
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_NETDEVICES=y
-CONFIG_MII=y
CONFIG_SMC91X=y
# CONFIG_WLAN is not set
CONFIG_INPUT_EVDEV=y
@@ -57,9 +56,9 @@ CONFIG_INPUT_EVDEV=y
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
CONFIG_FB=y
@@ -69,12 +68,13 @@ CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_USB_SUPPORT is not set
+CONFIG_VIRTIO_MMIO=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
-CONFIG_EXT4_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_EXT3_FS_XATTR is not set
+CONFIG_EXT4_FS=y
CONFIG_FUSE_FS=y
CONFIG_CUSE=y
CONFIG_VFAT_FS=y
@@ -84,12 +84,10 @@ CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
-CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
-CONFIG_DEBUG_INFO=y
# CONFIG_FTRACE is not set
CONFIG_ATOMIC64_SELFTEST=y
-CONFIG_VIRTIO_MMIO=y
-CONFIG_VIRTIO_BLK=y
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
` (4 preceding siblings ...)
2013-10-17 11:17 ` [PATCH RFC 5/6] arm64: Enable kprobes support for arm64 platform Sandeepa Prabhu
@ 2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-25 15:24 ` Will Deacon
2013-10-18 8:32 ` [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Masami Hiramatsu
6 siblings, 1 reply; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-17 11:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, patches, linaro-kernel, catalin.marinas,
will.deacon, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar,
Sandeepa Prabhu
Add info prints in sample kprobe handlers for ARM and ARM64
architecture.
Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
---
samples/kprobes/kprobe_example.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 366db1a..0521246 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -42,6 +42,14 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
" ex1 = 0x%lx\n",
p->addr, regs->pc, regs->ex1);
#endif
+#ifdef CONFIG_ARM
+ printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
+ p->addr, regs->ARM_pc);
+#endif
+#ifdef CONFIG_ARM64
+ printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
+ p->addr, (long)regs->pc);
+#endif
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -67,6 +75,14 @@ static void handler_post(struct kprobe *p, struct pt_regs *regs,
printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->addr, regs->ex1);
#endif
+#ifdef CONFIG_ARM
+ printk(KERN_INFO "post_handler: p->addr = 0x%p, pc = 0x%lx\n",
+ p->addr, regs->ARM_pc);
+#endif
+#ifdef CONFIG_ARM64
+ printk(KERN_INFO "post_handler: p->addr = 0x%p, pc = 0x%lx\n",
+ p->addr, (long)regs->pc);
+#endif
}
/*
--
1.8.1.2
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module
2013-10-17 11:17 ` [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module Sandeepa Prabhu
@ 2013-10-25 15:24 ` Will Deacon
2013-11-06 11:05 ` Sandeepa Prabhu
0 siblings, 1 reply; 50+ messages in thread
From: Will Deacon @ 2013-10-25 15:24 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On Thu, Oct 17, 2013 at 12:17:51PM +0100, Sandeepa Prabhu wrote:
> Add info prints in sample kprobe handlers for ARM and ARM64
> architecture.
>
> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
> ---
> samples/kprobes/kprobe_example.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
> index 366db1a..0521246 100644
> --- a/samples/kprobes/kprobe_example.c
> +++ b/samples/kprobes/kprobe_example.c
> @@ -42,6 +42,14 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> " ex1 = 0x%lx\n",
> p->addr, regs->pc, regs->ex1);
> #endif
> +#ifdef CONFIG_ARM
> + printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
> + p->addr, regs->ARM_pc);
> +#endif
> +#ifdef CONFIG_ARM64
> + printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
> + p->addr, (long)regs->pc);
> +#endif
Huh? Why can't you combine these two together and either unconditionall cast
to long, or use void * and %p?
Will
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module
2013-10-25 15:24 ` Will Deacon
@ 2013-11-06 11:05 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-11-06 11:05 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
Catalin Marinas, steve.capper, nico, srikar, rostedt,
masami.hiramatsu.pt, dsaxena, jiang.liu, Vijaya.Kumar
On 25 October 2013 20:54, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Oct 17, 2013 at 12:17:51PM +0100, Sandeepa Prabhu wrote:
>> Add info prints in sample kprobe handlers for ARM and ARM64
>> architecture.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
>> ---
>> samples/kprobes/kprobe_example.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
>> index 366db1a..0521246 100644
>> --- a/samples/kprobes/kprobe_example.c
>> +++ b/samples/kprobes/kprobe_example.c
>> @@ -42,6 +42,14 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
>> " ex1 = 0x%lx\n",
>> p->addr, regs->pc, regs->ex1);
>> #endif
>> +#ifdef CONFIG_ARM
>> + printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
>> + p->addr, regs->ARM_pc);
>> +#endif
>> +#ifdef CONFIG_ARM64
>> + printk(KERN_INFO "pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
>> + p->addr, (long)regs->pc);
>> +#endif
>
> Huh? Why can't you combine these two together and either unconditionall cast
> to long, or use void * and %p?
pt_regs member names are different: regs->pc (arm64) vs. regs->ARM_pc
(arm32). It is still possible to use instruction_pointer(regs) for
both architectures, but this needs including asm/ptrace.h which I am
not sure good thing to do in samples/
Thanks,
Sandeepa
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
` (5 preceding siblings ...)
2013-10-17 11:17 ` [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module Sandeepa Prabhu
@ 2013-10-18 8:32 ` Masami Hiramatsu
2013-10-21 4:17 ` Sandeepa Prabhu
6 siblings, 1 reply; 50+ messages in thread
From: Masami Hiramatsu @ 2013-10-18 8:32 UTC (permalink / raw)
To: Sandeepa Prabhu
Cc: linux-arm-kernel, linux-kernel, patches, linaro-kernel,
catalin.marinas, will.deacon, steve.capper, nico, srikar,
rostedt, dsaxena, jiang.liu, Vijaya.Kumar
(2013/10/17 20:17), Sandeepa Prabhu wrote:
> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
> and return probes(kretprobes) support for ARM64.
>
> Kprobes mechanism make use of software breakpoint and single stepping
> support available in ARM v8 kernel.
>
Thank you! This looks much better for me now. ;)
> This patchset make use of (and dependant upon) dynamic kernel patching
> feature published in patch series: https://lkml.org/lkml/2013/10/15/891
>
> changes: v1 -> v2
> 1. Implemented review comments on v1
> 2. Debug montior hooks implementation is changed to use rwlocks
> instead of rcu and spinlock.
Eventually, we'd better reconsider using rcu there, or prohibit probing
readlock related functions. For the first step, this will be good.
> 3. Enabled recursing in kprobes handler for kprobes re-enter support.
> 4. Re-split the patchset to seperate single-stepping, simulation and
> kretprobes features.
> 5. instruction simulation is made independent of 'struct kprobes'
> 6. Added 'Linaro Copyright' statements in new added files.
> 7. Used arm64 instead of aarch64 in file names and comments.
>
> Tested on ARM v8 fast model with sample modules from: samples/kprobes/
>
> Sandeepa Prabhu (6):
> arm64: support single-step and breakpoint handler hooks
> arm64: Kprobes with single stepping support
> arm64: Kprobes instruction simulation support
> arm64: Add kernel return probes support(kretprobes)
> arm64: Enable kprobes support for arm64 platform
> kprobes: Add cases for arm and arm64 in sample module
>
> arch/arm64/Kconfig | 2 +
> arch/arm64/configs/defconfig | 20 +-
> arch/arm64/include/asm/debug-monitors.h | 21 +
> arch/arm64/include/asm/kprobes.h | 60 +++
> arch/arm64/include/asm/probes.h | 50 +++
> arch/arm64/include/asm/ptrace.h | 6 +
> arch/arm64/kernel/Makefile | 2 +
> arch/arm64/kernel/condn-helpers.c | 120 ++++++
> arch/arm64/kernel/debug-monitors.c | 86 +++-
> arch/arm64/kernel/entry.S | 2 +
> arch/arm64/kernel/kprobes-arm64.c | 313 +++++++++++++++
> arch/arm64/kernel/kprobes-arm64.h | 30 ++
One comment, this name looks a bit wired. Since it seems that these are
for instruction decoding, can we merge it with probe-decode.h and
rename it as probe-decode.{h,c}? When we implement uprobes, we still
can expand it (add the decoding table for uprobes in the probe-decode.c).
> arch/arm64/kernel/kprobes.c | 682 ++++++++++++++++++++++++++++++++
> arch/arm64/kernel/kprobes.h | 30 ++
> arch/arm64/kernel/probes-decode.h | 110 ++++++
> arch/arm64/kernel/simulate-insn.c | 184 +++++++++
> arch/arm64/kernel/simulate-insn.h | 33 ++
> arch/arm64/kernel/vmlinux.lds.S | 1 +
> samples/kprobes/kprobe_example.c | 16 +
> 19 files changed, 1756 insertions(+), 12 deletions(-)
BTW, is there any public git repository which has this series?
Thank you again!
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support
2013-10-18 8:32 ` [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Masami Hiramatsu
@ 2013-10-21 4:17 ` Sandeepa Prabhu
0 siblings, 0 replies; 50+ messages in thread
From: Sandeepa Prabhu @ 2013-10-21 4:17 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: linux-arm-kernel, linux-kernel, Patch Tracking, linaro-kernel,
Catalin Marinas, Will Deacon, Steve Capper, Nicolas Pitre,
srikar, Steven Rostedt, Deepak Saxena, Jiang Liu, Vijaya Kumar K
On 18 October 2013 14:02, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> (2013/10/17 20:17), Sandeepa Prabhu wrote:
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>>
>> Kprobes mechanism make use of software breakpoint and single stepping
>> support available in ARM v8 kernel.
>>
>
> Thank you! This looks much better for me now. ;)
>
>> This patchset make use of (and dependant upon) dynamic kernel patching
>> feature published in patch series: https://lkml.org/lkml/2013/10/15/891
>>
>> changes: v1 -> v2
>> 1. Implemented review comments on v1
>> 2. Debug montior hooks implementation is changed to use rwlocks
>> instead of rcu and spinlock.
>
> Eventually, we'd better reconsider using rcu there, or prohibit probing
> readlock related functions. For the first step, this will be good.
Okay, can be done while optimizing kprobes right, since systemtap/ktap
is yet to be verified on this patchset,
so can expect more scope for optimizing the paths for performance.
>
>> 3. Enabled recursing in kprobes handler for kprobes re-enter support.
>> 4. Re-split the patchset to seperate single-stepping, simulation and
>> kretprobes features.
>> 5. instruction simulation is made independent of 'struct kprobes'
>> 6. Added 'Linaro Copyright' statements in new added files.
>> 7. Used arm64 instead of aarch64 in file names and comments.
>>
>> Tested on ARM v8 fast model with sample modules from: samples/kprobes/
>>
>> Sandeepa Prabhu (6):
>> arm64: support single-step and breakpoint handler hooks
>> arm64: Kprobes with single stepping support
>> arm64: Kprobes instruction simulation support
>> arm64: Add kernel return probes support(kretprobes)
>> arm64: Enable kprobes support for arm64 platform
>> kprobes: Add cases for arm and arm64 in sample module
>>
>> arch/arm64/Kconfig | 2 +
>> arch/arm64/configs/defconfig | 20 +-
>> arch/arm64/include/asm/debug-monitors.h | 21 +
>> arch/arm64/include/asm/kprobes.h | 60 +++
>> arch/arm64/include/asm/probes.h | 50 +++
>> arch/arm64/include/asm/ptrace.h | 6 +
>> arch/arm64/kernel/Makefile | 2 +
>> arch/arm64/kernel/condn-helpers.c | 120 ++++++
>> arch/arm64/kernel/debug-monitors.c | 86 +++-
>> arch/arm64/kernel/entry.S | 2 +
>
>
>> arch/arm64/kernel/kprobes-arm64.c | 313 +++++++++++++++
>> arch/arm64/kernel/kprobes-arm64.h | 30 ++
>
> One comment, this name looks a bit wired. Since it seems that these are
> for instruction decoding, can we merge it with probe-decode.h and
> rename it as probe-decode.{h,c}? When we implement uprobes, we still
> can expand it (add the decoding table for uprobes in the probe-decode.c).
probe-decode.c looks fine, as uprobes decode table can be added in
same place. -TODO for the next version.
>
>> arch/arm64/kernel/kprobes.c | 682 ++++++++++++++++++++++++++++++++
>> arch/arm64/kernel/kprobes.h | 30 ++
>> arch/arm64/kernel/probes-decode.h | 110 ++++++
>> arch/arm64/kernel/simulate-insn.c | 184 +++++++++
>> arch/arm64/kernel/simulate-insn.h | 33 ++
>> arch/arm64/kernel/vmlinux.lds.S | 1 +
>> samples/kprobes/kprobe_example.c | 16 +
>> 19 files changed, 1756 insertions(+), 12 deletions(-)
>
> BTW, is there any public git repository which has this series?
Yes, uploaded on linaro git:
https://git.linaro.org/gitweb?p=people/sandeepa.prabhu/linux-aarch64.git;a=shortlog;h=refs/heads/arm64-kprobes-v2
>
> Thank you again!
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>
^ permalink raw reply [flat|nested] 50+ messages in thread