Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753714AbaJTLAK (ORCPT ); Mon, 20 Oct 2014 07:00:10 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:44273 "EHLO e06smtp14.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753303AbaJTLAE (ORCPT ); Mon, 20 Oct 2014 07:00:04 -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 v2 0/2] s390 vs. kprobes on ftrace Date: Mon, 20 Oct 2014 12:59:52 +0200 Message-Id: <1413802794-38998-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: 14102011-0017-0000-0000-00000180BBB0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org v2: Changed patch 1/2 to incorporate feedback from Masami Hiramatsu, and introduce a new helper function check_ftrace_location(). The requested ftracetest has been sent as an own patch set, since it has no dependency to these patches. v1: 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 | 36 ++++++----- scripts/recordmcount.c | 2 +- scripts/recordmcount.pl | 2 +- 16 files changed, 239 insertions(+), 107 deletions(-) -- 1.8.5.5 -- 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/