On Mon, Nov 07, 2022 at 03:32:24PM +0000, Mark Rutland wrote: > On Mon, Nov 07, 2022 at 02:49:31PM +0000, Will Deacon wrote: > > [+Mark R] > > > > On Thu, Jul 28, 2022 at 02:02:50AM +0000, Jianlin Lv wrote: > > > This is the arm64 version of ftrace-based kprobes to avoid the overhead > > > with regular kprobes, by using the ftrace infrastructure. > > > > > > Signed-off-by: Jianlin Lv <iecedge@xxxxxxxxx> > > > --- > > > .../debug/kprobes-on-ftrace/arch-support.txt | 2 +- > > > arch/arm64/Kconfig | 1 + > > > arch/arm64/kernel/probes/Makefile | 1 + > > > arch/arm64/kernel/probes/kprobes-ftrace.c | 81 +++++++++++++++++++ > > > include/linux/kprobes.h | 2 + > > > kernel/kprobes.c | 4 +- > > > 6 files changed, 88 insertions(+), 3 deletions(-) > > > create mode 100644 arch/arm64/kernel/probes/kprobes-ftrace.c > > > > Sorry for the slow reply on this, but I think this deserved to be split > > into two patches: the first one reworking the core check_ftrace_location() > > logic to work properly with branch-and-link style architectures, and the > > second one adding support for arm64. > > I'd prefer we don't do this at all; there a bunch of issues with kprobes *not* > taking an exception, since we get a dodgy not-quite-real pt_regs, and to clean > up the existing issues the plan is: > > 1) Move ftrace over to ftrace_regs > 2) Implement fprobes using ftrace_regs > 3) Remove kretprobes > > ... and regular kprobes will need to take an exception (via BRK) to get a real > pt_regs, so that can't be optimized to use ftrace. OKey doke. Does that mean that other architectures will follow the same approach of taking an exception, or do they somehow work by magic? Will
