Jisheng Zhang wrote:
For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
correspondingly.
Signed-off-by: Jisheng Zhang
---
kernel/kprobes.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9873fc627d61..3fd2f68
Jisheng Zhang wrote:
KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
eliminates the need for a trap, as well as the need to emulate or
single-step instructions.
Tested on berlin arm64 platform.
~ # mount -t debugfs debugfs /sys/kernel/debug/
~ # cd /sys/kernel/debug/
/s
Signed-off-by: Jisheng Zhang
This looks good to me. Except for a small confirmation below:
Reviewed-by: Naveen N. Rao
---
KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
eliminates the need for a trap, as well as the need to emulate or
single-step instructions.
Applie
Jisheng Zhang wrote:
Hi,
On Thu, 22 Aug 2019 12:23:58 +0530
"Naveen N. Rao" wrote:
Jisheng Zhang wrote:
...
> +/* Ftrace callback handler for kprobes -- called under preepmt
> disabed */
> +void kprobe_ftrace_handler(unsigned long ip, unsi
Signed-off-by: Jisheng Zhang
Reviewed-by: Naveen N. Rao
- Naveen
Masami Hiramatsu wrote:
On Mon, 7 May 2018 13:51:21 +0530
Ravi Bangoria wrote:
BTW, same issue exists for normal uprobe. If uprobe_mmap() fails,
there is no feedback to trace_uprobe and no warnigns in dmesg as
well !! There was a patch by Naveen to warn such failures in dmesg
but that didn't g
