From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751585AbaJOPq2 (ORCPT ); Wed, 15 Oct 2014 11:46:28 -0400 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:48049 "EHLO e06smtp17.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751262AbaJOPq0 (ORCPT ); Wed, 15 Oct 2014 11:46:26 -0400 From: Heiko Carstens To: Ananth N Mavinakayanahalli , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Ingo Molnar Cc: Vojtech Pavlik , Jiri Kosina , Jiri Slaby , Steven Rostedt , Martin Schwidefsky , linux-kernel@vger.kernel.org, Heiko Carstens Subject: [PATCH 0/2] s390 vs. kprobes on ftrace Date: Wed, 15 Oct 2014 17:46:16 +0200 Message-Id: <1413387978-984-1-git-send-email-heiko.carstens@de.ibm.com> X-Mailer: git-send-email 1.8.5.5 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14101515-0029-0000-0000-00000135863F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, we would like to implement an architecture specific variant of "kprobes on ftrace" without using the current HAVE_KPROBES_ON_FTRACE infrastructure which is currently only used by x86. The rationale for these two patches is: - we want to patch the first instruction of the mcount code block to reduce the overhead of the function tracer - we'd like to keep the ftrace_caller function as simple as possible and not require it to generate a 100% valid pt_regs structure as required by the combination of DYNAMIC_FTRACE_WITH_REGS and HAVE_KPROBES_ON_FTRACE. This allows us to not generate the psw mask field in the pt_regs structure on each function tracer enabled function, which otherwise would be very expensive. Besides that program check generated pt_regs contents are "more" accurate than program generated ones and don't require any maintenance. And also we can keep the ftrace and kprobes backends quite separated. In order to make this work a small common code change is necessary which removes a check if kprobe is being placed on an ftrace location (see first patch). If possible, I'd like to have an ACK from at least one of the kprobes maintainers for the first patch and bring it upstream via the s390 tree. Thanks, Heiko Heiko Carstens (2): kprobes: introduce ARCH_HANDLES_KPROBES_ON_FTRACE s390/ftrace,kprobes: allow to patch first instruction arch/Kconfig | 8 +++ arch/s390/Kconfig | 1 + arch/s390/include/asm/ftrace.h | 52 ++++++++++++++-- arch/s390/include/asm/kprobes.h | 1 + arch/s390/include/asm/lowcore.h | 4 +- arch/s390/include/asm/pgtable.h | 12 ++++ arch/s390/kernel/asm-offsets.c | 1 - arch/s390/kernel/early.c | 4 -- arch/s390/kernel/ftrace.c | 132 +++++++++++++++++++++++++--------------- arch/s390/kernel/kprobes.c | 87 ++++++++++++++++++-------- arch/s390/kernel/mcount.S | 1 + arch/s390/kernel/setup.c | 2 - arch/s390/kernel/smp.c | 1 - kernel/kprobes.c | 3 +- scripts/recordmcount.c | 2 +- scripts/recordmcount.pl | 2 +- 16 files changed, 220 insertions(+), 93 deletions(-) -- 1.8.5.5