From: "Singh, Balbir" <bsingharora@gmail.com> To: Torsten Duwe <duwe@lst.de> Cc: Mark Rutland <mark.rutland@arm.com>, Will Deacon <will.deacon@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Julien Thierry <julien.thierry@arm.com>, Steven Rostedt <rostedt@goodmis.org>, Josh Poimboeuf <jpoimboe@redhat.com>, Ingo Molnar <mingo@redhat.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Arnd Bergmann <arnd@arndb.de>, AKASHI Takahiro <takahiro.akashi@linaro.org>, Amit Daniel Kachhap <amit.kachhap@arm.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH v7 2/3] arm64: implement ftrace with regs Date: Thu, 24 Jan 2019 09:38:02 +1300 [thread overview] Message-ID: <79927f69-3276-4c3f-5f60-b7159d340d43@gmail.com> (raw) In-Reply-To: <20190122130958.GA16778@lst.de> On 1/23/19 2:09 AM, Torsten Duwe wrote: > Hi Balbir! > Hi, Torsten! > On Tue, Jan 22, 2019 at 02:39:32PM +1300, Singh, Balbir wrote: >> >> On 1/19/19 5:39 AM, Torsten Duwe wrote: >>> + */ >>> +ftrace_common_return: >>> + /* restore function args */ >>> + ldp x0, x1, [sp] >>> + ldp x2, x3, [sp, #S_X2] >>> + ldp x4, x5, [sp, #S_X4] >>> + ldp x6, x7, [sp, #S_X6] >>> + ldr x8, [sp, #S_X8] >>> + >>> + /* restore fp and x28 */ >>> + ldp x28, x29, [sp, #S_X28] >>> + >>> + ldr lr, [sp, #S_LR] >>> + ldr x9, [sp, #S_PC] >> >> Is it fair to assume that we never modify registers beyond LR and PC as a result of ftrace/livepatching? I presume it is, but just checking. > > These are either callee-save or scratch. Whatever is called, ftrace framework > functions or replacement functions, must preserve the callee-saved regs; and > the caller, who made a function call (sic!-) saves caller-saved and marks the > rest dead on return. So it's the arguments that matter after all. > > As you can see, disabling IPA-RA is cruicial here. > > Or are you talking about deliberate argument manipulation? I wonder if another use of ftrace via register_ftrace_ops can expect to modify arguments, like we modify the PC and RA > >>> + unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET; >>> + u32 old, new; >>> + >>> + old = aarch64_insn_gen_branch_imm(pc, old_addr, true); >>> + new = aarch64_insn_gen_branch_imm(pc, addr, true); >>> + >> >> Is this a branch or a call? Does addr always fit in the immediate limits? > > As Julien has now pointed out, the correct enum value AARCH64_INSN_BRANCH_LINK > should clarify this. It will surely fit for the kernel proper, and the modules > are handled with the trampolines. OK, so there is an assumption of the size of vmlinux being in a certain range? I suspect something like a allyesconfig with debug might be a worthy challenger :) Yes, modules do get trampolines. > >>> + return ftrace_modify_code(pc, old, new, true); >> >> Can you talk to the semantics of whether this operation is atomic w.r.t system? Will old and new return consistent values? Given the nature of ftrace, I presume it's well isolated. > > aarch64_insn_patch_text_nosync() does a __flush_icache_range() on success. > Mark wrote that this is already sufficient IIRC. (I had memory barriers > there, when I was still trying to modify 2 insns every time). > >> >>> + if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS) && >>> + addr == MCOUNT_ADDR) { >>> + old = aarch64_insn_gen_nop(); >>> + new = MOV_X9_X30; >>> + pc -= REC_IP_BRANCH_OFFSET; >>> + return ftrace_modify_code(pc, old, new, validate); >> >> I presume all the icache flush and barrier handling is in ftrace_modify_code()? > > Yes, see above. > Thanks! >>> + } >>> + >>> if (offset < -SZ_128M || offset >= SZ_128M) { >>> #ifdef CONFIG_ARM64_MODULE_PLTS >>> u32 replaced; >>> --- a/arch/arm64/include/asm/module.h >>> +++ b/arch/arm64/include/asm/module.h >>> @@ -32,7 +32,8 @@ struct mod_arch_specific { >>> struct mod_plt_sec init; >>> >>> /* for CONFIG_DYNAMIC_FTRACE */ >>> - struct plt_entry *ftrace_trampoline; >>> + struct plt_entry *ftrace_trampolines; >>> +#define MOD_ARCH_NR_FTRACE_TRAMPOLINES 2 >> >> I don't see the generation of ftrace_trampolines[1] >> > > That was further up, install_ftrace_trampoline() in kernel/ftrace.c. > Thanks! > + if (*addr == FTRACE_ADDR) > + mod_trampoline = &mod->arch.ftrace_trampolines[0]; > + else if (*addr == FTRACE_REGS_ADDR) > + mod_trampoline = &mod->arch.ftrace_trampolines[1]; > [...] > + trampoline = get_plt_entry(*addr, mod_trampoline); > + > + if (!plt_entries_equal(mod_trampoline, &trampoline)) { > [...] > > get_plt_entry() generates a small bunch of instructions that easily > fit into the argument registers. Compare commit bdb85cd1d20669dfae8 > for the new trampoline insns. > > Hope I've covered all your concerns, > Yes, largely thank you Balbir
WARNING: multiple messages have this Message-ID (diff)
From: "Singh, Balbir" <bsingharora@gmail.com> To: Torsten Duwe <duwe@lst.de> Cc: Mark Rutland <mark.rutland@arm.com>, Arnd Bergmann <arnd@arndb.de>, Julien Thierry <julien.thierry@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>, AKASHI Takahiro <takahiro.akashi@linaro.org>, Ingo Molnar <mingo@redhat.com>, Josh Poimboeuf <jpoimboe@redhat.com>, Amit Daniel Kachhap <amit.kachhap@arm.com>, live-patching@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 2/3] arm64: implement ftrace with regs Date: Thu, 24 Jan 2019 09:38:02 +1300 [thread overview] Message-ID: <79927f69-3276-4c3f-5f60-b7159d340d43@gmail.com> (raw) In-Reply-To: <20190122130958.GA16778@lst.de> On 1/23/19 2:09 AM, Torsten Duwe wrote: > Hi Balbir! > Hi, Torsten! > On Tue, Jan 22, 2019 at 02:39:32PM +1300, Singh, Balbir wrote: >> >> On 1/19/19 5:39 AM, Torsten Duwe wrote: >>> + */ >>> +ftrace_common_return: >>> + /* restore function args */ >>> + ldp x0, x1, [sp] >>> + ldp x2, x3, [sp, #S_X2] >>> + ldp x4, x5, [sp, #S_X4] >>> + ldp x6, x7, [sp, #S_X6] >>> + ldr x8, [sp, #S_X8] >>> + >>> + /* restore fp and x28 */ >>> + ldp x28, x29, [sp, #S_X28] >>> + >>> + ldr lr, [sp, #S_LR] >>> + ldr x9, [sp, #S_PC] >> >> Is it fair to assume that we never modify registers beyond LR and PC as a result of ftrace/livepatching? I presume it is, but just checking. > > These are either callee-save or scratch. Whatever is called, ftrace framework > functions or replacement functions, must preserve the callee-saved regs; and > the caller, who made a function call (sic!-) saves caller-saved and marks the > rest dead on return. So it's the arguments that matter after all. > > As you can see, disabling IPA-RA is cruicial here. > > Or are you talking about deliberate argument manipulation? I wonder if another use of ftrace via register_ftrace_ops can expect to modify arguments, like we modify the PC and RA > >>> + unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET; >>> + u32 old, new; >>> + >>> + old = aarch64_insn_gen_branch_imm(pc, old_addr, true); >>> + new = aarch64_insn_gen_branch_imm(pc, addr, true); >>> + >> >> Is this a branch or a call? Does addr always fit in the immediate limits? > > As Julien has now pointed out, the correct enum value AARCH64_INSN_BRANCH_LINK > should clarify this. It will surely fit for the kernel proper, and the modules > are handled with the trampolines. OK, so there is an assumption of the size of vmlinux being in a certain range? I suspect something like a allyesconfig with debug might be a worthy challenger :) Yes, modules do get trampolines. > >>> + return ftrace_modify_code(pc, old, new, true); >> >> Can you talk to the semantics of whether this operation is atomic w.r.t system? Will old and new return consistent values? Given the nature of ftrace, I presume it's well isolated. > > aarch64_insn_patch_text_nosync() does a __flush_icache_range() on success. > Mark wrote that this is already sufficient IIRC. (I had memory barriers > there, when I was still trying to modify 2 insns every time). > >> >>> + if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS) && >>> + addr == MCOUNT_ADDR) { >>> + old = aarch64_insn_gen_nop(); >>> + new = MOV_X9_X30; >>> + pc -= REC_IP_BRANCH_OFFSET; >>> + return ftrace_modify_code(pc, old, new, validate); >> >> I presume all the icache flush and barrier handling is in ftrace_modify_code()? > > Yes, see above. > Thanks! >>> + } >>> + >>> if (offset < -SZ_128M || offset >= SZ_128M) { >>> #ifdef CONFIG_ARM64_MODULE_PLTS >>> u32 replaced; >>> --- a/arch/arm64/include/asm/module.h >>> +++ b/arch/arm64/include/asm/module.h >>> @@ -32,7 +32,8 @@ struct mod_arch_specific { >>> struct mod_plt_sec init; >>> >>> /* for CONFIG_DYNAMIC_FTRACE */ >>> - struct plt_entry *ftrace_trampoline; >>> + struct plt_entry *ftrace_trampolines; >>> +#define MOD_ARCH_NR_FTRACE_TRAMPOLINES 2 >> >> I don't see the generation of ftrace_trampolines[1] >> > > That was further up, install_ftrace_trampoline() in kernel/ftrace.c. > Thanks! > + if (*addr == FTRACE_ADDR) > + mod_trampoline = &mod->arch.ftrace_trampolines[0]; > + else if (*addr == FTRACE_REGS_ADDR) > + mod_trampoline = &mod->arch.ftrace_trampolines[1]; > [...] > + trampoline = get_plt_entry(*addr, mod_trampoline); > + > + if (!plt_entries_equal(mod_trampoline, &trampoline)) { > [...] > > get_plt_entry() generates a small bunch of instructions that easily > fit into the argument registers. Compare commit bdb85cd1d20669dfae8 > for the new trampoline insns. > > Hope I've covered all your concerns, > Yes, largely thank you Balbir _______________________________________________ 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:[~2019-01-23 20:38 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-18 16:37 [PATCH v7 0/3] arm64: ftrace with regs Torsten Duwe 2019-01-18 16:37 ` Torsten Duwe 2019-01-18 16:39 ` [PATCH v7 1/3] arm64: replace -pg with CC_FLAGS_FTRACE in Makefiles Torsten Duwe 2019-01-18 16:39 ` Torsten Duwe 2019-01-18 17:24 ` Mark Rutland 2019-01-18 17:24 ` Mark Rutland 2019-01-18 16:39 ` [PATCH v7 2/3] arm64: implement ftrace with regs Torsten Duwe 2019-01-18 16:39 ` Torsten Duwe 2019-01-22 1:39 ` Singh, Balbir 2019-01-22 1:39 ` Singh, Balbir 2019-01-22 13:09 ` Torsten Duwe 2019-01-22 13:09 ` Torsten Duwe 2019-01-23 20:38 ` Singh, Balbir [this message] 2019-01-23 20:38 ` Singh, Balbir 2019-01-22 10:18 ` Julien Thierry 2019-01-22 10:18 ` Julien Thierry 2019-01-22 13:28 ` Torsten Duwe 2019-01-22 13:28 ` Torsten Duwe 2019-01-22 13:49 ` Julien Thierry 2019-01-22 13:49 ` Julien Thierry 2019-01-22 13:55 ` Ard Biesheuvel 2019-01-22 13:55 ` Ard Biesheuvel 2019-02-04 12:03 ` Torsten Duwe 2019-02-04 12:03 ` Torsten Duwe 2019-02-04 13:43 ` Ard Biesheuvel 2019-02-04 13:43 ` Ard Biesheuvel 2019-02-06 8:59 ` Julien Thierry 2019-02-06 8:59 ` Julien Thierry 2019-02-06 9:30 ` Julien Thierry 2019-02-06 9:30 ` Julien Thierry 2019-02-06 14:09 ` Steven Rostedt 2019-02-06 14:09 ` Steven Rostedt 2019-02-06 15:05 ` Torsten Duwe 2019-02-06 15:05 ` Torsten Duwe 2019-02-07 10:33 ` Julien Thierry 2019-02-07 10:33 ` Julien Thierry 2019-02-07 12:51 ` Torsten Duwe 2019-02-07 12:51 ` Torsten Duwe 2019-02-07 13:47 ` Julien Thierry 2019-02-07 13:47 ` Julien Thierry 2019-02-07 14:51 ` Steven Rostedt 2019-02-07 14:51 ` Steven Rostedt 2019-02-07 14:58 ` Julien Thierry 2019-02-07 14:58 ` Julien Thierry 2019-02-07 15:00 ` Torsten Duwe 2019-02-07 15:00 ` Torsten Duwe 2019-04-03 2:48 ` Mark Rutland 2019-04-03 2:48 ` Mark Rutland 2019-04-03 12:30 ` Steven Rostedt 2019-04-03 12:30 ` Steven Rostedt 2019-04-03 13:05 ` Torsten Duwe 2019-04-03 13:05 ` Torsten Duwe 2019-01-18 16:39 ` [PATCH v7 3/3] arm64: use -fpatchable-function-entry if available Torsten Duwe 2019-01-18 16:39 ` Torsten Duwe
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=79927f69-3276-4c3f-5f60-b7159d340d43@gmail.com \ --to=bsingharora@gmail.com \ --cc=amit.kachhap@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=duwe@lst.de \ --cc=jpoimboe@redhat.com \ --cc=julien.thierry@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=live-patching@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=rostedt@goodmis.org \ --cc=takahiro.akashi@linaro.org \ --cc=will.deacon@arm.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.