From: Mark Rutland <mark.rutland@arm.com> To: Steven Rostedt <rostedt@goodmis.org> Cc: Wang ShaoBo <bobo.shaobowang@huawei.com>, cj.chengjian@huawei.com, huawei.libin@huawei.com, xiexiuqi@huawei.com, liwei391@huawei.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, zengshun.wu@outlook.com Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Date: Fri, 22 Apr 2022 11:12:39 +0100 [thread overview] Message-ID: <YmJ/l4vJoEpFt68l@FVFF77S0Q05N> (raw) In-Reply-To: <20220421130648.56b21951@gandalf.local.home> On Thu, Apr 21, 2022 at 01:06:48PM -0400, Steven Rostedt wrote: > On Thu, 21 Apr 2022 17:27:40 +0100 > Mark Rutland <mark.rutland@arm.com> wrote: > > > We can initialize the ops pointer to a default ops that does the whole > > __do_for_each_ftrace_ops() dance. > > OK, I think I understand now. What you are doing is instead of creating a > trampoline that has all the information in the trampoline, you add nops to > all the functions where you can place the information in the nops (before > the function), and then have the trampoline just read that information to > find the ops pointer as well as the function to call. Yup! > I guess you could have two trampolines as well. One that always calls the > list loop, and one that calls the data stored in front of the function that > was just called the trampoline. As it is always safe to call the loop > function, you could have the call call that trampoline first, set up the > specific data before the function, then call the trampoline that will read > it. And same thing for tear down. Having separate trampolines is possible, but there are some complications, and we might end up with an explosion of trampolines (and associated module PLTs) due to needing BTI/!BTI and REGs/!REGS variants, so if it's possible to have a default ops that handled the list case, that'd be my preference to keep that simple and manageable. As an aside, I'd also love to remove the REGS/!REGs distinction, and always save a minimum amount of state (like ARGS, but never saving a full pt_regs), since on arm64 the extra state stored for the REGS case isn't useful (and we can't reliably capture all of the pt_regs state anyway, so bits of it are made up or not filled in). Thanks, Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Steven Rostedt <rostedt@goodmis.org> Cc: Wang ShaoBo <bobo.shaobowang@huawei.com>, cj.chengjian@huawei.com, huawei.libin@huawei.com, xiexiuqi@huawei.com, liwei391@huawei.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, zengshun.wu@outlook.com Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Date: Fri, 22 Apr 2022 11:12:39 +0100 [thread overview] Message-ID: <YmJ/l4vJoEpFt68l@FVFF77S0Q05N> (raw) In-Reply-To: <20220421130648.56b21951@gandalf.local.home> On Thu, Apr 21, 2022 at 01:06:48PM -0400, Steven Rostedt wrote: > On Thu, 21 Apr 2022 17:27:40 +0100 > Mark Rutland <mark.rutland@arm.com> wrote: > > > We can initialize the ops pointer to a default ops that does the whole > > __do_for_each_ftrace_ops() dance. > > OK, I think I understand now. What you are doing is instead of creating a > trampoline that has all the information in the trampoline, you add nops to > all the functions where you can place the information in the nops (before > the function), and then have the trampoline just read that information to > find the ops pointer as well as the function to call. Yup! > I guess you could have two trampolines as well. One that always calls the > list loop, and one that calls the data stored in front of the function that > was just called the trampoline. As it is always safe to call the loop > function, you could have the call call that trampoline first, set up the > specific data before the function, then call the trampoline that will read > it. And same thing for tear down. Having separate trampolines is possible, but there are some complications, and we might end up with an explosion of trampolines (and associated module PLTs) due to needing BTI/!BTI and REGs/!REGS variants, so if it's possible to have a default ops that handled the list case, that'd be my preference to keep that simple and manageable. As an aside, I'd also love to remove the REGS/!REGs distinction, and always save a minimum amount of state (like ARGS, but never saving a full pt_regs), since on arm64 the extra state stored for the REGS case isn't useful (and we can't reliably capture all of the pt_regs state anyway, so bits of it are made up or not filled in). Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-22 10:12 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-16 10:01 [RFC PATCH -next v2 0/4] arm64/ftrace: support dynamic trampoline Wang ShaoBo 2022-03-16 10:01 ` Wang ShaoBo 2022-03-16 10:01 ` [RFC PATCH -next v2 1/4] arm64: introduce aarch64_insn_gen_load_literal Wang ShaoBo 2022-03-16 10:01 ` Wang ShaoBo 2022-03-16 10:01 ` [RFC PATCH -next v2 2/4] arm64/ftrace: introduce ftrace dynamic trampoline entrances Wang ShaoBo 2022-03-16 10:01 ` Wang ShaoBo 2022-03-16 10:01 ` [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Wang ShaoBo 2022-03-16 10:01 ` Wang ShaoBo 2022-04-21 13:10 ` Mark Rutland 2022-04-21 13:10 ` Mark Rutland 2022-04-21 14:06 ` Steven Rostedt 2022-04-21 14:06 ` Steven Rostedt 2022-04-21 14:08 ` Steven Rostedt 2022-04-21 14:08 ` Steven Rostedt 2022-04-21 15:14 ` Mark Rutland 2022-04-21 15:14 ` Mark Rutland 2022-04-21 15:42 ` Steven Rostedt 2022-04-21 15:42 ` Steven Rostedt 2022-04-21 16:27 ` Mark Rutland 2022-04-21 16:27 ` Mark Rutland 2022-04-21 17:06 ` Steven Rostedt 2022-04-21 17:06 ` Steven Rostedt 2022-04-22 10:12 ` Mark Rutland [this message] 2022-04-22 10:12 ` Mark Rutland 2022-04-22 15:45 ` Steven Rostedt 2022-04-22 15:45 ` Steven Rostedt 2022-04-22 17:27 ` Mark Rutland 2022-04-22 17:27 ` Mark Rutland 2022-04-26 8:47 ` Masami Hiramatsu 2022-04-26 8:47 ` Masami Hiramatsu 2022-05-04 10:24 ` Mark Rutland 2022-05-04 10:24 ` Mark Rutland 2022-05-05 3:15 ` Masami Hiramatsu 2022-05-05 3:15 ` Masami Hiramatsu 2022-05-09 18:22 ` Steven Rostedt 2022-05-09 18:22 ` Steven Rostedt 2022-05-10 9:10 ` Masami Hiramatsu 2022-05-10 9:10 ` Masami Hiramatsu 2022-05-10 14:44 ` Steven Rostedt 2022-05-10 14:44 ` Steven Rostedt 2022-05-11 14:34 ` Masami Hiramatsu 2022-05-11 14:34 ` Masami Hiramatsu 2022-05-11 15:12 ` Steven Rostedt 2022-05-11 15:12 ` Steven Rostedt 2022-05-12 12:02 ` Masami Hiramatsu 2022-05-12 12:02 ` Masami Hiramatsu 2022-05-12 13:50 ` Steven Rostedt 2022-05-12 13:50 ` Steven Rostedt 2022-05-25 12:17 ` Mark Rutland 2022-05-25 12:17 ` Mark Rutland 2022-05-25 13:43 ` Steven Rostedt 2022-05-25 13:43 ` Steven Rostedt 2022-05-25 17:12 ` Mark Rutland 2022-05-25 17:12 ` Mark Rutland 2022-05-30 1:03 ` Masami Hiramatsu 2022-05-30 1:03 ` Masami Hiramatsu 2022-05-30 12:38 ` Jiri Olsa 2022-05-30 12:38 ` Jiri Olsa 2022-05-31 1:00 ` Masami Hiramatsu 2022-05-31 1:00 ` Masami Hiramatsu 2022-05-04 12:43 ` Mark Rutland 2022-05-04 12:43 ` Mark Rutland 2022-05-05 2:57 ` Wangshaobo (bobo) 2022-05-05 2:57 ` Wangshaobo (bobo) 2022-05-25 12:27 ` Mark Rutland 2022-05-25 12:27 ` Mark Rutland 2022-04-27 8:54 ` Wangshaobo (bobo) 2022-04-27 8:54 ` Wangshaobo (bobo) 2022-03-16 10:01 ` [RFC PATCH -next v2 4/4] arm64/ftrace: implement long jump for dynamic trampolines Wang ShaoBo 2022-03-16 10:01 ` Wang ShaoBo 2022-04-21 13:47 ` Mark Rutland 2022-04-21 13:47 ` Mark Rutland 2022-03-16 14:29 ` [RFC PATCH -next v2 0/4] arm64/ftrace: support dynamic trampoline Steven Rostedt 2022-03-16 14:29 ` Steven Rostedt 2022-04-20 18:11 ` Steven Rostedt 2022-04-20 18:11 ` Steven Rostedt 2022-04-21 1:13 ` Wangshaobo (bobo) 2022-04-21 1:13 ` Wangshaobo (bobo) 2022-04-21 12:37 ` Steven Rostedt 2022-04-21 12:37 ` Steven Rostedt 2022-05-25 12:45 ` Mark Rutland 2022-05-25 12:45 ` Mark Rutland 2022-05-25 13:58 ` Steven Rostedt 2022-05-25 13:58 ` Steven Rostedt 2022-05-25 17:26 ` Mark Rutland 2022-05-25 17:26 ` Mark Rutland 2022-04-21 12:53 ` Mark Rutland 2022-04-21 12:53 ` Mark Rutland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YmJ/l4vJoEpFt68l@FVFF77S0Q05N \ --to=mark.rutland@arm.com \ --cc=bobo.shaobowang@huawei.com \ --cc=catalin.marinas@arm.com \ --cc=cj.chengjian@huawei.com \ --cc=huawei.libin@huawei.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=liwei391@huawei.com \ --cc=rostedt@goodmis.org \ --cc=will@kernel.org \ --cc=xiexiuqi@huawei.com \ --cc=zengshun.wu@outlook.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.