From: Mark Rutland <mark.rutland@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, amit.kachhap@arm.com,
catalin.marinas@arm.com, deller@gmx.de, duwe@suse.de,
James.Bottomley@HansenPartnership.com, james.morse@arm.com,
jeyu@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com,
linux-parisc@vger.kernel.org, mark.rutland@arm.com,
mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org,
svens@stackframe.org, takahiro.akashi@linaro.org,
will@kernel.org
Subject: [PATCHv2 4/8] arm64: module/ftrace: intialize PLT at load time
Date: Tue, 29 Oct 2019 16:58:28 +0000 [thread overview]
Message-ID: <20191029165832.33606-5-mark.rutland@arm.com> (raw)
In-Reply-To: <20191029165832.33606-1-mark.rutland@arm.com>
Currently we lazily-initialize a module's ftrace PLT at runtime when we
install the first ftrace call. To do so we have to apply a number of
sanity checks, transiently mark the module text as RW, and perform an
IPI as part of handling Neoverse-N1 erratum #1542419.
We only expect the ftrace trampoline to point at ftrace_caller() (AKA
FTRACE_ADDR), so let's simplify all of this by intializing the PLT at
module load time, before the module loader marks the module RO and
performs the intial I-cache maintenance for the module.
Thus we can rely on the module having been correctly intialized, and can
simplify the runtime work necessary to install an ftrace call in a
module. This will also allow for the removal of module_disable_ro().
Tested by forcing ftrace_make_call() to use the module PLT, and then
loading up a module after setting up ftrace with:
| echo ":mod:<module-name>" > set_ftrace_filter;
| echo function > current_tracer;
| modprobe <module-name>
Since FTRACE_ADDR is only defined when CONFIG_DYNAMIC_FTRACE is
selected, we wrap its use along with most of module_init_ftrace_plt()
with ifdeffery rather than using IS_ENABLED().
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/ftrace.c | 55 ++++++++++++----------------------------------
arch/arm64/kernel/module.c | 32 +++++++++++++++++----------
2 files changed, 35 insertions(+), 52 deletions(-)
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 06e56b470315..822718eafdb4 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -73,10 +73,22 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
if (offset < -SZ_128M || offset >= SZ_128M) {
#ifdef CONFIG_ARM64_MODULE_PLTS
- struct plt_entry trampoline, *dst;
struct module *mod;
/*
+ * There is only one ftrace trampoline per module. For now,
+ * this is not a problem since on arm64, all dynamic ftrace
+ * invocations are routed via ftrace_caller(). This will need
+ * to be revisited if support for multiple ftrace entry points
+ * is added in the future, but for now, the pr_err() below
+ * deals with a theoretical issue only.
+ */
+ if (addr != FTRACE_ADDR) {
+ pr_err("ftrace: far branches to multiple entry points unsupported inside a single module\n");
+ return -EINVAL;
+ }
+
+ /*
* On kernels that support module PLTs, the offset between the
* branch instruction and its target may legally exceed the
* range of an ordinary relative 'bl' opcode. In this case, we
@@ -93,46 +105,7 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
if (WARN_ON(!mod))
return -EINVAL;
- /*
- * There is only one ftrace trampoline per module. For now,
- * this is not a problem since on arm64, all dynamic ftrace
- * invocations are routed via ftrace_caller(). This will need
- * to be revisited if support for multiple ftrace entry points
- * is added in the future, but for now, the pr_err() below
- * deals with a theoretical issue only.
- *
- * Note that PLTs are place relative, and plt_entries_equal()
- * checks whether they point to the same target. Here, we need
- * to check if the actual opcodes are in fact identical,
- * regardless of the offset in memory so use memcmp() instead.
- */
- dst = mod->arch.ftrace_trampoline;
- trampoline = get_plt_entry(addr, dst);
- if (memcmp(dst, &trampoline, sizeof(trampoline))) {
- if (plt_entry_is_initialized(dst)) {
- pr_err("ftrace: far branches to multiple entry points unsupported inside a single module\n");
- return -EINVAL;
- }
-
- /* point the trampoline to our ftrace entry point */
- module_disable_ro(mod);
- *dst = trampoline;
- module_enable_ro(mod, true);
-
- /*
- * Ensure updated trampoline is visible to instruction
- * fetch before we patch in the branch. Although the
- * architecture doesn't require an IPI in this case,
- * Neoverse-N1 erratum #1542419 does require one
- * if the TLB maintenance in module_enable_ro() is
- * skipped due to rodata_enabled. It doesn't seem worth
- * it to make it conditional given that this is
- * certainly not a fast-path.
- */
- flush_icache_range((unsigned long)&dst[0],
- (unsigned long)&dst[1]);
- }
- addr = (unsigned long)dst;
+ addr = (unsigned long)mod->arch.ftrace_trampoline;
#else /* CONFIG_ARM64_MODULE_PLTS */
return -EINVAL;
#endif /* CONFIG_ARM64_MODULE_PLTS */
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 763a86d52fef..5f5bc3b94da7 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -9,6 +9,7 @@
#include <linux/bitops.h>
#include <linux/elf.h>
+#include <linux/ftrace.h>
#include <linux/gfp.h>
#include <linux/kasan.h>
#include <linux/kernel.h>
@@ -485,24 +486,33 @@ static const Elf_Shdr *find_section(const Elf_Ehdr *hdr,
return NULL;
}
+int module_init_ftrace_plt(const Elf_Ehdr *hdr,
+ const Elf_Shdr *sechdrs,
+ struct module *mod)
+{
+#if defined(CONFIG_ARM64_MODULE_PLTS) && defined(CONFIG_DYNAMIC_FTRACE)
+ const Elf_Shdr *s;
+ struct plt_entry *plt;
+
+ s = find_section(hdr, sechdrs, ".text.ftrace_trampoline");
+ if (!s)
+ return -ENOEXEC;
+
+ plt = (void *)s->sh_addr;
+ *plt = get_plt_entry(FTRACE_ADDR, plt);
+ mod->arch.ftrace_trampoline = plt;
+#endif
+ return 0;
+}
+
int module_finalize(const Elf_Ehdr *hdr,
const Elf_Shdr *sechdrs,
struct module *me)
{
const Elf_Shdr *s;
-
s = find_section(hdr, sechdrs, ".altinstructions");
if (s)
apply_alternatives_module((void *)s->sh_addr, s->sh_size);
-#ifdef CONFIG_ARM64_MODULE_PLTS
- if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE)) {
- s = find_section(hdr, sechdrs, ".text.ftrace_trampoline");
- if (!s)
- return -ENOEXEC;
- me->arch.ftrace_trampoline = (void *)s->sh_addr;
- }
-#endif
-
- return 0;
+ return module_init_ftrace_plt(hdr, sechdrs, me);
}
--
2.11.0
next prev parent reply other threads:[~2019-10-29 16:59 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 16:58 [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Mark Rutland
2019-10-29 16:58 ` [PATCHv2 1/8] ftrace: add ftrace_init_nop() Mark Rutland
2019-10-30 15:00 ` Miroslav Benes
2019-11-02 12:19 ` Amit Daniel Kachhap
2019-11-04 13:11 ` Steven Rostedt
2019-11-05 6:59 ` Amit Kachhap
2019-11-04 13:36 ` Mark Rutland
2019-11-05 6:47 ` Amit Kachhap
2019-11-06 14:15 ` Mark Rutland
2019-11-07 4:40 ` Amit Kachhap
2019-11-04 13:16 ` Steven Rostedt
2019-11-04 13:38 ` Mark Rutland
2019-11-04 13:53 ` Steven Rostedt
2019-10-29 16:58 ` [PATCHv2 2/8] module/ftrace: handle patchable-function-entry Mark Rutland
2019-10-30 15:03 ` Torsten Duwe
2019-10-31 9:02 ` Mark Rutland
2019-10-31 11:42 ` Torsten Duwe
2019-10-31 13:00 ` Mark Rutland
2019-11-04 13:28 ` Steven Rostedt
2019-11-04 14:00 ` Mark Rutland
2019-11-04 13:25 ` Steven Rostedt
2019-11-04 15:51 ` Mark Rutland
2019-11-04 20:58 ` Helge Deller
2019-11-05 8:59 ` Miroslav Benes
2019-10-29 16:58 ` [PATCHv2 3/8] arm64: module: rework special section handling Mark Rutland
2019-10-30 15:25 ` Miroslav Benes
2019-10-29 16:58 ` Mark Rutland [this message]
2019-11-02 12:20 ` [PATCHv2 4/8] arm64: module/ftrace: intialize PLT at load time Amit Daniel Kachhap
2019-11-04 13:55 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 5/8] arm64: insn: add encoder for MOV (register) Mark Rutland
2019-10-29 16:58 ` [PATCHv2 6/8] arm64: asm-offsets: add S_FP Mark Rutland
2019-10-29 16:58 ` [PATCHv2 7/8] arm64: implement ftrace with regs Mark Rutland
2019-11-02 12:21 ` Amit Daniel Kachhap
2019-11-04 13:51 ` Mark Rutland
[not found] ` <CANW9uyug8WKN2fR-FmcW-C_OO_OQ_AvukM+BR7wqiJ9eFQMO9Q@mail.gmail.com>
2019-11-15 7:45 ` Torsten Duwe
2019-11-15 13:59 ` Mark Rutland
2019-10-29 16:58 ` [PATCHv2 8/8] arm64: ftrace: minimize ifdeffery Mark Rutland
2019-10-30 17:02 ` [PATCHv2 0/8] arm64: ftrace cleanup + FTRACE_WITH_REGS Torsten Duwe
2019-10-31 17:16 ` Torsten Duwe
2019-11-01 9:08 ` Mark Rutland
2019-11-01 15:39 ` Sven Schnelle
2019-11-01 16:28 ` Mark Rutland
2019-11-02 12:12 ` Amit Daniel Kachhap
2019-11-04 12:56 ` Will Deacon
2019-11-04 13:03 ` Amit Kachhap
2019-11-04 14:04 ` Mark Rutland
2019-11-05 7:06 ` Amit Kachhap
2019-11-07 11:31 ` Catalin Marinas
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=20191029165832.33606-5-mark.rutland@arm.com \
--to=mark.rutland@arm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=amit.kachhap@arm.com \
--cc=catalin.marinas@arm.com \
--cc=deller@gmx.de \
--cc=duwe@suse.de \
--cc=james.morse@arm.com \
--cc=jeyu@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=svens@stackframe.org \
--cc=takahiro.akashi@linaro.org \
--cc=will@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).