Message ID | 20221103170520.931305-1-mark.rutland@arm.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp655852wru; Thu, 3 Nov 2022 10:08:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6BdnUFdOcJrxsuXrfITFCEMjvxThjL9gU42UjGIHF0CqceVMDNO4L7S5XE5GHi3dB+QDi6 X-Received: by 2002:a17:90b:1d90:b0:213:d0a2:72ab with SMTP id pf16-20020a17090b1d9000b00213d0a272abmr25542529pjb.221.1667495294388; Thu, 03 Nov 2022 10:08:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667495294; cv=none; d=google.com; s=arc-20160816; b=jCUbAm0Pp1V/KWw5CTrc6kw1R/MR/rnzioMpt8PloDWVKz6Yml1olzBU4rdKqPtRKM w/q8PBfNWaCnGk3ygUPEAHaefjZoe+z2q+pyMFCYQBcYkXGevY7BtK3Yxe9ODMmM+KgV hy2kJ5lARyrMRsNaVgluKBv9QQXNZ8aE9Eb4NaTGKKbYL+Mn5GstUplunhOVoSR3YRZr +6c2yH3P3/xCk/4p3etgzEGDcPNlRGwcOnkGbo4rVPbKZfFVZ32vGaaKDs4ELSfTcLeu DZ2L6ZeJxJoEhdBSTUdnmvBW+bt853zN739V/B/L5JtUnBbXk4kT87FUjY554R98W6+c oaqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=3kr7SdFOB5fTlM5a/rkkloRIlL6WQBEmZLpKj8NOqvQ=; b=Fl1I+XKnBibn3goy6jzFYg4Hj8TjjAGgrlRAHY8jXjhPKQOo1sM5zbh64dgdw8QFBM piQ1RDgXeLCvegl8xV0/P2hamPaEdufQ2kFU5ns64sPoljm7VMoeEhpI4q6sGQcqNFa8 HA/JrTbtLB7ub4RUeMokdC1sD8HnZsmVwGGcRzK96REx/TVMDI/7tWwTcK8j+7YhKxo9 YQ4aN6TeQDBQb4btf/UB6U+6JqOmk7Ix5iDWj5agadtBTiqJe9hNeEgCJVGySsAGxC+m DRyUbqnkCsWcy/DLMYJQhGktUNrK12xnpwGNx4D2WvGdHKHaU4r51kvCS2Jms502U53c kA8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l9-20020a17090270c900b00186c6205f0fsi1196982plt.385.2022.11.03.10.08.00; Thu, 03 Nov 2022 10:08:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231934AbiKCRGl (ORCPT <rfc822;yves.mi.zy@gmail.com> + 99 others); Thu, 3 Nov 2022 13:06:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231947AbiKCRF5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Nov 2022 13:05:57 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 10E406276 for <linux-kernel@vger.kernel.org>; Thu, 3 Nov 2022 10:05:29 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 533C61FB; Thu, 3 Nov 2022 10:05:35 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8B1683F5A1; Thu, 3 Nov 2022 10:05:27 -0700 (PDT) From: Mark Rutland <mark.rutland@arm.com> To: linux-kernel@vger.kernel.org Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, mhiramat@kernel.org, revest@chromium.org, rostedt@goodmis.org, will@kernel.org Subject: [PATCH v2 0/4] arm64/ftrace: move to DYNAMIC_FTRACE_WITH_ARGS Date: Thu, 3 Nov 2022 17:05:16 +0000 Message-Id: <20221103170520.931305-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748495545846046802?= X-GMAIL-MSGID: =?utf-8?q?1748495545846046802?= |
Series |
arm64/ftrace: move to DYNAMIC_FTRACE_WITH_ARGS
|
|
Message
Mark Rutland
Nov. 3, 2022, 5:05 p.m. UTC
This series replaces arm64's support for FTRACE_WITH_REGS with support for FTRACE_WITH_ARGS. This removes some overhead and complexity, and removes some latent issues with inconsistent presentation of struct pt_regs (which can only be reliably saved/restored at exception boundaries). The existing FTRACE_WITH_REGS support was added for two major reasons: (1) To make it possible to use the ftrace graph tracer with pointer authentication, where it's necessary to snapshot/manipulate the LR before it is signed by the instrumented function. (2) To make it possible to implement LIVEPATCH in future, where we need to hook function entry before an instrumented function manipulates the stack or argument registers. Practically speaking, we need to preserve the argument/return registers, PC, LR, and SP. Neither of these requires the full set of pt_regs, and only requires us to save/restore a subset of registers used for passing arguments/return-values and context/return information (which is the minimum set we always need to save/restore today). As there is no longer a need to save different sets of registers for different features, we no longer need distinct `ftrace_caller` and `ftrace_regs_caller` trampolines. This allows the trampoline assembly to be simpler, and simplifies code which previously had to handle the two trampolines. I've tested this with the ftrace selftests, where there are no unexpected failures. I plan to build atop this with subsequent patches to add per-callsite ftrace_ops, and I'm sending these patches on their own as I think they make sense regardless. Since v1 [1]: * Change ifdeferry per Steve's request * Add ftrace_regs_query_register_offset() per Masami's request * Fix a bunch of typos [1] https://lore.kernel.org/lkml/20221024140846.3555435-1-mark.rutland@arm.com This series can be found in my 'arm64/ftrace/minimal-regs' branch on kernel.org: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/ git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git This version is tagged as: arm64-ftrace-minimal-regs-20221103 Thanks, Mark. Mark Rutland (4): ftrace: pass fregs to arch_ftrace_set_direct_caller() ftrace: rename ftrace_instruction_pointer_set() -> ftrace_regs_set_instruction_pointer() ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses ftrace: arm64: move from REGS to ARGS arch/arm64/Kconfig | 18 +++-- arch/arm64/Makefile | 2 +- arch/arm64/include/asm/ftrace.h | 72 ++++++++++++++++-- arch/arm64/kernel/asm-offsets.c | 13 ++++ arch/arm64/kernel/entry-ftrace.S | 117 ++++++++++++------------------ arch/arm64/kernel/ftrace.c | 82 ++++++++++++--------- arch/arm64/kernel/module.c | 3 - arch/powerpc/include/asm/ftrace.h | 24 +++++- arch/s390/include/asm/ftrace.h | 29 +++++++- arch/x86/include/asm/ftrace.h | 49 +++++++++---- include/linux/ftrace.h | 47 +++++++++--- kernel/livepatch/patch.c | 2 +- kernel/trace/Kconfig | 6 +- kernel/trace/ftrace.c | 3 +- 14 files changed, 309 insertions(+), 158 deletions(-)
Comments
On Thu, 3 Nov 2022 17:05:16 +0000 Mark Rutland <mark.rutland@arm.com> wrote: > This series replaces arm64's support for FTRACE_WITH_REGS with support > for FTRACE_WITH_ARGS. This removes some overhead and complexity, and > removes some latent issues with inconsistent presentation of struct > pt_regs (which can only be reliably saved/restored at exception > boundaries). > > The existing FTRACE_WITH_REGS support was added for two major reasons: > > (1) To make it possible to use the ftrace graph tracer with pointer > authentication, where it's necessary to snapshot/manipulate the LR > before it is signed by the instrumented function. > > (2) To make it possible to implement LIVEPATCH in future, where we need > to hook function entry before an instrumented function manipulates > the stack or argument registers. Practically speaking, we need to > preserve the argument/return registers, PC, LR, and SP. > > Neither of these requires the full set of pt_regs, and only requires us > to save/restore a subset of registers used for passing > arguments/return-values and context/return information (which is the > minimum set we always need to save/restore today). > > As there is no longer a need to save different sets of registers for > different features, we no longer need distinct `ftrace_caller` and > `ftrace_regs_caller` trampolines. This allows the trampoline assembly to > be simpler, and simplifies code which previously had to handle the two > trampolines. > > I've tested this with the ftrace selftests, where there are no > unexpected failures. Were there any "expected" failures? > > I plan to build atop this with subsequent patches to add per-callsite > ftrace_ops, and I'm sending these patches on their own as I think they > make sense regardless. > > Since v1 [1]: > * Change ifdeferry per Steve's request > * Add ftrace_regs_query_register_offset() per Masami's request > * Fix a bunch of typos > > [1] https://lore.kernel.org/lkml/20221024140846.3555435-1-mark.rutland@arm.com > > This series can be found in my 'arm64/ftrace/minimal-regs' branch on > kernel.org: > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/ > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git > > This version is tagged as: > > arm64-ftrace-minimal-regs-20221103 So I ran this on top of my code through all my ftrace tests (for x86) and it didn't cause any regressions. Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> -- Steve
On Tue, Nov 15, 2022 at 10:01:48AM -0500, Steven Rostedt wrote: > On Thu, 3 Nov 2022 17:05:16 +0000 > Mark Rutland <mark.rutland@arm.com> wrote: > > > This series replaces arm64's support for FTRACE_WITH_REGS with support > > for FTRACE_WITH_ARGS. This removes some overhead and complexity, and > > removes some latent issues with inconsistent presentation of struct > > pt_regs (which can only be reliably saved/restored at exception > > boundaries). > > > > The existing FTRACE_WITH_REGS support was added for two major reasons: > > > > (1) To make it possible to use the ftrace graph tracer with pointer > > authentication, where it's necessary to snapshot/manipulate the LR > > before it is signed by the instrumented function. > > > > (2) To make it possible to implement LIVEPATCH in future, where we need > > to hook function entry before an instrumented function manipulates > > the stack or argument registers. Practically speaking, we need to > > preserve the argument/return registers, PC, LR, and SP. > > > > Neither of these requires the full set of pt_regs, and only requires us > > to save/restore a subset of registers used for passing > > arguments/return-values and context/return information (which is the > > minimum set we always need to save/restore today). > > > > As there is no longer a need to save different sets of registers for > > different features, we no longer need distinct `ftrace_caller` and > > `ftrace_regs_caller` trampolines. This allows the trampoline assembly to > > be simpler, and simplifies code which previously had to handle the two > > trampolines. > > > > I've tested this with the ftrace selftests, where there are no > > unexpected failures. > > Were there any "expected" failures? Ah; sorry, I had meant to include the results here. With this series applied atop v6.1-rc4 and using the ftrace selftests from that tree, my results were the same as with baseline v6.1-rc4: | # of passed: 104 | # of failed: 0 | # of unresolved: 7 | # of untested: 0 | # of unsupported: 2 | # of xfailed: 1 | # of undefined(test bug): 0 Where the non-passing tests were: | [8] Test ftrace direct functions against tracers [UNRESOLVED] | [9] Test ftrace direct functions against kprobes [UNRESOLVED] ... as direct functions aren't supported on arm64 (both before and after this series). | [16] Generic dynamic event - check if duplicate events are caught [UNSUPPORTED] | [74] event trigger - test inter-event histogram trigger eprobe on synthetic event [UNSUPPORTED] ... which are due to a bug in the tests fixed by: https://lore.kernel.org/all/20221010074207.714077-1-svens@linux.ibm.com/ ... and they both pass with that applied. | [22] Test trace_printk from module [UNRESOLVED] | [31] ftrace - function trace on module [UNRESOLVED] | [51] Kprobe dynamic event - probing module [UNRESOLVED] | [61] test for the preemptirqsoff tracer [UNRESOLVED] ... which are because my test environment didn't have modules. | [62] Meta-selftest: Checkbashisms [UNRESOLVED] ... which is irrelevant for this series. | [65] event trigger - test inter-event histogram trigger expected fail actions [XFAIL] ... which is expected. [...] > So I ran this on top of my code through all my ftrace tests (for x86) and > it didn't cause any regressions. > > Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Thanks! Mark.
On Thu, 3 Nov 2022 17:05:16 +0000 Mark Rutland <mark.rutland@arm.com> wrote: > This series replaces arm64's support for FTRACE_WITH_REGS with support > for FTRACE_WITH_ARGS. This removes some overhead and complexity, and > removes some latent issues with inconsistent presentation of struct > pt_regs (which can only be reliably saved/restored at exception > boundaries). > > The existing FTRACE_WITH_REGS support was added for two major reasons: > > (1) To make it possible to use the ftrace graph tracer with pointer > authentication, where it's necessary to snapshot/manipulate the LR > before it is signed by the instrumented function. > > (2) To make it possible to implement LIVEPATCH in future, where we need > to hook function entry before an instrumented function manipulates > the stack or argument registers. Practically speaking, we need to > preserve the argument/return registers, PC, LR, and SP. > > Neither of these requires the full set of pt_regs, and only requires us > to save/restore a subset of registers used for passing > arguments/return-values and context/return information (which is the > minimum set we always need to save/restore today). > > As there is no longer a need to save different sets of registers for > different features, we no longer need distinct `ftrace_caller` and > `ftrace_regs_caller` trampolines. This allows the trampoline assembly to > be simpler, and simplifies code which previously had to handle the two > trampolines. > > I've tested this with the ftrace selftests, where there are no > unexpected failures. > > I plan to build atop this with subsequent patches to add per-callsite > ftrace_ops, and I'm sending these patches on their own as I think they > make sense regardless. Thanks! this series looks good to me. Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> So it is the good time to rewrite the new fprobe event handler based on these interfaces :) > > Since v1 [1]: > * Change ifdeferry per Steve's request > * Add ftrace_regs_query_register_offset() per Masami's request > * Fix a bunch of typos > > [1] https://lore.kernel.org/lkml/20221024140846.3555435-1-mark.rutland@arm.com > > This series can be found in my 'arm64/ftrace/minimal-regs' branch on > kernel.org: > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/ > git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git > > This version is tagged as: > > arm64-ftrace-minimal-regs-20221103 > > Thanks, > Mark. > > Mark Rutland (4): > ftrace: pass fregs to arch_ftrace_set_direct_caller() > ftrace: rename ftrace_instruction_pointer_set() -> > ftrace_regs_set_instruction_pointer() > ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses > ftrace: arm64: move from REGS to ARGS > > arch/arm64/Kconfig | 18 +++-- > arch/arm64/Makefile | 2 +- > arch/arm64/include/asm/ftrace.h | 72 ++++++++++++++++-- > arch/arm64/kernel/asm-offsets.c | 13 ++++ > arch/arm64/kernel/entry-ftrace.S | 117 ++++++++++++------------------ > arch/arm64/kernel/ftrace.c | 82 ++++++++++++--------- > arch/arm64/kernel/module.c | 3 - > arch/powerpc/include/asm/ftrace.h | 24 +++++- > arch/s390/include/asm/ftrace.h | 29 +++++++- > arch/x86/include/asm/ftrace.h | 49 +++++++++---- > include/linux/ftrace.h | 47 +++++++++--- > kernel/livepatch/patch.c | 2 +- > kernel/trace/Kconfig | 6 +- > kernel/trace/ftrace.c | 3 +- > 14 files changed, 309 insertions(+), 158 deletions(-) > > -- > 2.30.2 >
On Thu, 3 Nov 2022 17:05:16 +0000, Mark Rutland wrote: > This series replaces arm64's support for FTRACE_WITH_REGS with support > for FTRACE_WITH_ARGS. This removes some overhead and complexity, and > removes some latent issues with inconsistent presentation of struct > pt_regs (which can only be reliably saved/restored at exception > boundaries). > > The existing FTRACE_WITH_REGS support was added for two major reasons: > > [...] Applied to arm64 (for-next/ftrace), thanks! [1/4] ftrace: pass fregs to arch_ftrace_set_direct_caller() https://git.kernel.org/arm64/c/9705bc709604 [2/4] ftrace: rename ftrace_instruction_pointer_set() -> ftrace_regs_set_instruction_pointer() https://git.kernel.org/arm64/c/0ef86097f127 [3/4] ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses https://git.kernel.org/arm64/c/94d095ffa0e1 [4/4] ftrace: arm64: move from REGS to ARGS https://git.kernel.org/arm64/c/26299b3f6ba2 Cheers,