AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity
473043dcee
kernel_optimize_test/include/asm-arm/kprobes.h

80 lines
2.1 KiB
C
Raw Normal View History

ARM kprobes: instruction single-stepping support This is the code implementing instruction single-stepping for kprobes on ARM. To get around the limitation of no Next-PC and no hardware single- stepping, all kprobe'd instructions are split into three camps: simulation, emulation, and rejected. "Simulated" instructions are those instructions which behavior is reproduced by straight C code. "Emulated" instructions are ones that are copied, slightly altered and executed directly in the instruction slot to reproduce their behavior. "Rejected" instructions are ones that could be simulated, but work hasn't been put into simulating them. These instructions should be very rare, if not unencountered, in the kernel. If ever needed, code could be added to simulate them. One might wonder why this and the ptrace singlestep facility are not sharing some code. Both approaches are fundamentally different because the ptrace code regains control after the stepped instruction by installing a breakpoint after the instruction itself, and possibly at the location where the instruction might be branching to, instead of simulating or emulating the target instruction. The ptrace approach isn't suitable for kprobes because the breakpoints would have to be moved back, and the icache flushed, everytime the probe is hit to let normal code execution resume, which would have a significant performance impact. It is also racy on SMP since another CPU could, with the right timing, sail through the probe point without being caught. Because ptrace single-stepping always result in a different process to be scheduled, the concern for performance is much less significant. On the other hand, the kprobes approach isn't (currently) suitable for ptrace because it has no provision for proper user space memory protection and translation, and even if that was implemented, the gain wouldn't be worth the added complexity in the ptrace path compared to the current approach. So, until kprobes does support user space, both kprobes and ptrace are best kept independent and separate. Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
/*
* include/asm-arm/kprobes.h
*
* Copyright (C) 2006, 2007 Motorola Inc.
*
* 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>
ARM kprobes: core code This is a full implementation of Kprobes including Jprobes and Kretprobes support. This ARM implementation does not follow the usual kprobes double- exception model. The traditional model is where the initial kprobes breakpoint calls kprobe_handler(), which returns from exception to execute the instruction in its original context, then immediately re-enters after a second breakpoint (or single-stepping exception) into post_kprobe_handler(), each time the probe is hit.. The ARM implementation only executes one kprobes exception per hit, so no post_kprobe_handler() phase. All side-effects from the kprobe'd instruction are resolved before returning from the initial exception. As a result, all instructions are _always_ effectively boosted regardless of the type of instruction, and even regardless of whether or not there is a post-handler for the probe. Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
#include <linux/percpu.h>
#define ARCH_SUPPORTS_KRETPROBES
#define __ARCH_WANT_KPROBES_INSN_SLOT
#define MAX_INSN_SIZE 2
#define MAX_STACK_SIZE 64 /* 32 would probably be OK */
ARM kprobes: special hook for the kprobes breakpoint handler The kprobes code is already able to cope with reentrant probes, so its handler must be called outside of the region protected by undef_lock. If ever this lock is released when handlers are called then this commit could be reverted. Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-12-04 06:22:36 +08:00
/*
* This undefined instruction must be unique and
* reserved solely for kprobes' use.
*/
#define KPROBE_BREAKPOINT_INSTRUCTION 0xe7f001f8
ARM kprobes: core code This is a full implementation of Kprobes including Jprobes and Kretprobes support. This ARM implementation does not follow the usual kprobes double- exception model. The traditional model is where the initial kprobes breakpoint calls kprobe_handler(), which returns from exception to execute the instruction in its original context, then immediately re-enters after a second breakpoint (or single-stepping exception) into post_kprobe_handler(), each time the probe is hit.. The ARM implementation only executes one kprobes exception per hit, so no post_kprobe_handler() phase. All side-effects from the kprobe'd instruction are resolved before returning from the initial exception. As a result, all instructions are _always_ effectively boosted regardless of the type of instruction, and even regardless of whether or not there is a post-handler for the probe. Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
#define regs_return_value(regs) ((regs)->ARM_r0)
#define flush_insn_slot(p) do { } while (0)
#define kretprobe_blacklist_size 0
ARM kprobes: instruction single-stepping support This is the code implementing instruction single-stepping for kprobes on ARM. To get around the limitation of no Next-PC and no hardware single- stepping, all kprobe'd instructions are split into three camps: simulation, emulation, and rejected. "Simulated" instructions are those instructions which behavior is reproduced by straight C code. "Emulated" instructions are ones that are copied, slightly altered and executed directly in the instruction slot to reproduce their behavior. "Rejected" instructions are ones that could be simulated, but work hasn't been put into simulating them. These instructions should be very rare, if not unencountered, in the kernel. If ever needed, code could be added to simulate them. One might wonder why this and the ptrace singlestep facility are not sharing some code. Both approaches are fundamentally different because the ptrace code regains control after the stepped instruction by installing a breakpoint after the instruction itself, and possibly at the location where the instruction might be branching to, instead of simulating or emulating the target instruction. The ptrace approach isn't suitable for kprobes because the breakpoints would have to be moved back, and the icache flushed, everytime the probe is hit to let normal code execution resume, which would have a significant performance impact. It is also racy on SMP since another CPU could, with the right timing, sail through the probe point without being caught. Because ptrace single-stepping always result in a different process to be scheduled, the concern for performance is much less significant. On the other hand, the kprobes approach isn't (currently) suitable for ptrace because it has no provision for proper user space memory protection and translation, and even if that was implemented, the gain wouldn't be worth the added complexity in the ptrace path compared to the current approach. So, until kprobes does support user space, both kprobes and ptrace are best kept independent and separate. Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
typedef u32 kprobe_opcode_t;
struct kprobe;
typedef void (kprobe_insn_handler_t)(struct kprobe *, struct pt_regs *);
/* Architecture specific copy of original instruction. */
struct arch_specific_insn {
kprobe_opcode_t *insn;
kprobe_insn_handler_t *insn_handler;
};
ARM kprobes: core code This is a full implementation of Kprobes including Jprobes and Kretprobes support. This ARM implementation does not follow the usual kprobes double- exception model. The traditional model is where the initial kprobes breakpoint calls kprobe_handler(), which returns from exception to execute the instruction in its original context, then immediately re-enters after a second breakpoint (or single-stepping exception) into post_kprobe_handler(), each time the probe is hit.. The ARM implementation only executes one kprobes exception per hit, so no post_kprobe_handler() phase. All side-effects from the kprobe'd instruction are resolved before returning from the initial exception. As a result, all instructions are _always_ effectively boosted regardless of the type of instruction, and even regardless of whether or not there is a post-handler for the probe. Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
struct prev_kprobe {
struct kprobe *kp;
unsigned int status;
};
/* per-cpu kprobe control block */
struct kprobe_ctlblk {
unsigned int kprobe_status;
struct prev_kprobe prev_kprobe;
struct pt_regs jprobe_saved_regs;
char jprobes_stack[MAX_STACK_SIZE];
};
void arch_remove_kprobe(struct kprobe *);
ARM kprobes: special hook for the kprobes breakpoint handler The kprobes code is already able to cope with reentrant probes, so its handler must be called outside of the region protected by undef_lock. If ever this lock is released when handlers are called then this commit could be reverted. Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-12-04 06:22:36 +08:00
int kprobe_trap_handler(struct pt_regs *regs, unsigned int instr);
ARM kprobes: core code This is a full implementation of Kprobes including Jprobes and Kretprobes support. This ARM implementation does not follow the usual kprobes double- exception model. The traditional model is where the initial kprobes breakpoint calls kprobe_handler(), which returns from exception to execute the instruction in its original context, then immediately re-enters after a second breakpoint (or single-stepping exception) into post_kprobe_handler(), each time the probe is hit.. The ARM implementation only executes one kprobes exception per hit, so no post_kprobe_handler() phase. All side-effects from the kprobe'd instruction are resolved before returning from the initial exception. As a result, all instructions are _always_ effectively boosted regardless of the type of instruction, and even regardless of whether or not there is a post-handler for the probe. Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
ARM kprobes: instruction single-stepping support This is the code implementing instruction single-stepping for kprobes on ARM. To get around the limitation of no Next-PC and no hardware single- stepping, all kprobe'd instructions are split into three camps: simulation, emulation, and rejected. "Simulated" instructions are those instructions which behavior is reproduced by straight C code. "Emulated" instructions are ones that are copied, slightly altered and executed directly in the instruction slot to reproduce their behavior. "Rejected" instructions are ones that could be simulated, but work hasn't been put into simulating them. These instructions should be very rare, if not unencountered, in the kernel. If ever needed, code could be added to simulate them. One might wonder why this and the ptrace singlestep facility are not sharing some code. Both approaches are fundamentally different because the ptrace code regains control after the stepped instruction by installing a breakpoint after the instruction itself, and possibly at the location where the instruction might be branching to, instead of simulating or emulating the target instruction. The ptrace approach isn't suitable for kprobes because the breakpoints would have to be moved back, and the icache flushed, everytime the probe is hit to let normal code execution resume, which would have a significant performance impact. It is also racy on SMP since another CPU could, with the right timing, sail through the probe point without being caught. Because ptrace single-stepping always result in a different process to be scheduled, the concern for performance is much less significant. On the other hand, the kprobes approach isn't (currently) suitable for ptrace because it has no provision for proper user space memory protection and translation, and even if that was implemented, the gain wouldn't be worth the added complexity in the ptrace path compared to the current approach. So, until kprobes does support user space, both kprobes and ptrace are best kept independent and separate. Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-12 06:20:10 +08:00
enum kprobe_insn {
INSN_REJECTED,
INSN_GOOD,
INSN_GOOD_NO_SLOT
};
enum kprobe_insn arm_kprobe_decode_insn(kprobe_opcode_t,
struct arch_specific_insn *);
void __init arm_kprobe_decode_init(void);
#endif /* _ARM_KPROBES_H */
Copy Permalink