Message ID | 20200903203053.3411268-6-samitolvanen@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Add support for Clang LTO | expand |
On Thu, Sep 03, 2020 at 01:30:30PM -0700, Sami Tolvanen wrote: > From: Peter Zijlstra <peterz@infradead.org> > > Add the --mcount option for generating __mcount_loc sections > needed for dynamic ftrace. Using this pass requires the kernel to > be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined > in Makefile. > > Link: https://lore.kernel.org/lkml/20200625200235.GQ4781@hirez.programming.kicks-ass.net/ > Signed-off-by: Peter Zijlstra <peterz@infradead.org> Hmm, I'm not sure why this hasn't gotten picked up yet. Is this expected to go through -tip or something else? Reviewed-by: Kees Cook <keescook@chromium.org>
On Thu, Sep 3, 2020 at 2:51 PM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Sep 03, 2020 at 01:30:30PM -0700, Sami Tolvanen wrote: > > From: Peter Zijlstra <peterz@infradead.org> > > > > Add the --mcount option for generating __mcount_loc sections > > needed for dynamic ftrace. Using this pass requires the kernel to > > be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined > > in Makefile. > > > > Link: https://lore.kernel.org/lkml/20200625200235.GQ4781@hirez.programming.kicks-ass.net/ > > Signed-off-by: Peter Zijlstra <peterz@infradead.org> > > Hmm, I'm not sure why this hasn't gotten picked up yet. Is this expected > to go through -tip or something else? Note that I picked up this patch from Peter's original email, to which I included a link in the commit message, but it wasn't officially submitted as a patch. However, the previous discussion seems to have died, so I included the patch in this series, as it cleanly solves the problem of whitelisting non-call references to __fentry__. I was hoping for Peter and Steven to comment on how they prefer to proceed here. Sami
On Thu, Sep 03, 2020 at 03:03:30PM -0700, Sami Tolvanen wrote: > On Thu, Sep 3, 2020 at 2:51 PM Kees Cook <keescook@chromium.org> wrote: > > > > On Thu, Sep 03, 2020 at 01:30:30PM -0700, Sami Tolvanen wrote: > > > From: Peter Zijlstra <peterz@infradead.org> > > > > > > Add the --mcount option for generating __mcount_loc sections > > > needed for dynamic ftrace. Using this pass requires the kernel to > > > be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined > > > in Makefile. > > > > > > Link: https://lore.kernel.org/lkml/20200625200235.GQ4781@hirez.programming.kicks-ass.net/ > > > Signed-off-by: Peter Zijlstra <peterz@infradead.org> > > > > Hmm, I'm not sure why this hasn't gotten picked up yet. Is this expected > > to go through -tip or something else? > > Note that I picked up this patch from Peter's original email, to which > I included a link in the commit message, but it wasn't officially > submitted as a patch. However, the previous discussion seems to have > died, so I included the patch in this series, as it cleanly solves the > problem of whitelisting non-call references to __fentry__. I was > hoping for Peter and Steven to comment on how they prefer to proceed > here. Right; so I'm obviously fine with this patch and I suppose I can pick it (and the next) into tip/objtool/core, provided Steve is okay with this approach.
On Fri, Sep 04, 2020 at 11:31:04AM +0200, peterz@infradead.org wrote: > On Thu, Sep 03, 2020 at 03:03:30PM -0700, Sami Tolvanen wrote: > > On Thu, Sep 3, 2020 at 2:51 PM Kees Cook <keescook@chromium.org> wrote: > > > > > > On Thu, Sep 03, 2020 at 01:30:30PM -0700, Sami Tolvanen wrote: > > > > From: Peter Zijlstra <peterz@infradead.org> > > > > > > > > Add the --mcount option for generating __mcount_loc sections > > > > needed for dynamic ftrace. Using this pass requires the kernel to > > > > be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined > > > > in Makefile. > > > > > > > > Link: https://lore.kernel.org/lkml/20200625200235.GQ4781@hirez.programming.kicks-ass.net/ > > > > Signed-off-by: Peter Zijlstra <peterz@infradead.org> > > > > > > Hmm, I'm not sure why this hasn't gotten picked up yet. Is this expected > > > to go through -tip or something else? > > > > Note that I picked up this patch from Peter's original email, to which > > I included a link in the commit message, but it wasn't officially > > submitted as a patch. However, the previous discussion seems to have > > died, so I included the patch in this series, as it cleanly solves the > > problem of whitelisting non-call references to __fentry__. I was > > hoping for Peter and Steven to comment on how they prefer to proceed > > here. > > Right; so I'm obviously fine with this patch and I suppose I can pick it > (and the next) into tip/objtool/core, provided Steve is okay with this > approach. Hello Steven-of-the-future-after-4000-emails![1] ;) Getting your Ack on this would be very welcome, and would unblock a portion of this series. Thanks! :) [1] https://twitter.com/srostedt/status/1303697650592755712
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c index 7a44174967b5..71595cf4946d 100644 --- a/tools/objtool/builtin-check.c +++ b/tools/objtool/builtin-check.c @@ -18,7 +18,7 @@ #include "builtin.h" #include "objtool.h" -bool no_fp, no_unreachable, retpoline, module, backtrace, uaccess, stats, validate_dup, vmlinux; +bool no_fp, no_unreachable, retpoline, module, backtrace, uaccess, stats, validate_dup, vmlinux, mcount; static const char * const check_usage[] = { "objtool check [<options>] file.o", @@ -35,6 +35,7 @@ const struct option check_options[] = { OPT_BOOLEAN('s', "stats", &stats, "print statistics"), OPT_BOOLEAN('d', "duplicate", &validate_dup, "duplicate validation for vmlinux.o"), OPT_BOOLEAN('l', "vmlinux", &vmlinux, "vmlinux.o validation"), + OPT_BOOLEAN('M', "mcount", &mcount, "generate __mcount_loc"), OPT_END(), }; diff --git a/tools/objtool/builtin.h b/tools/objtool/builtin.h index 85c979caa367..94565a72b701 100644 --- a/tools/objtool/builtin.h +++ b/tools/objtool/builtin.h @@ -8,7 +8,7 @@ #include <subcmd/parse-options.h> extern const struct option check_options[]; -extern bool no_fp, no_unreachable, retpoline, module, backtrace, uaccess, stats, validate_dup, vmlinux; +extern bool no_fp, no_unreachable, retpoline, module, backtrace, uaccess, stats, validate_dup, vmlinux, mcount; extern int cmd_check(int argc, const char **argv); extern int cmd_orc(int argc, const char **argv); diff --git a/tools/objtool/check.c b/tools/objtool/check.c index e034a8f24f46..6e0b478dc065 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -433,6 +433,65 @@ static int add_dead_ends(struct objtool_file *file) return 0; } +static int create_mcount_loc_sections(struct objtool_file *file) +{ + struct section *sec, *reloc_sec; + struct reloc *reloc; + unsigned long *loc; + struct instruction *insn; + int idx; + + sec = find_section_by_name(file->elf, "__mcount_loc"); + if (sec) { + INIT_LIST_HEAD(&file->mcount_loc_list); + WARN("file already has __mcount_loc section, skipping"); + return 0; + } + + if (list_empty(&file->mcount_loc_list)) + return 0; + + idx = 0; + list_for_each_entry(insn, &file->mcount_loc_list, mcount_loc_node) + idx++; + + sec = elf_create_section(file->elf, "__mcount_loc", sizeof(unsigned long), idx); + if (!sec) + return -1; + + reloc_sec = elf_create_reloc_section(file->elf, sec, SHT_RELA); + if (!reloc_sec) + return -1; + + idx = 0; + list_for_each_entry(insn, &file->mcount_loc_list, mcount_loc_node) { + + loc = (unsigned long *)sec->data->d_buf + idx; + memset(loc, 0, sizeof(unsigned long)); + + reloc = malloc(sizeof(*reloc)); + if (!reloc) { + perror("malloc"); + return -1; + } + memset(reloc, 0, sizeof(*reloc)); + + reloc->sym = insn->sec->sym; + reloc->addend = insn->offset; + reloc->type = R_X86_64_64; + reloc->offset = idx * sizeof(unsigned long); + reloc->sec = reloc_sec; + elf_add_reloc(file->elf, reloc); + + idx++; + } + + if (elf_rebuild_reloc_section(file->elf, reloc_sec)) + return -1; + + return 0; +} + /* * Warnings shouldn't be reported for ignored functions. */ @@ -784,6 +843,22 @@ static int add_call_destinations(struct objtool_file *file) insn->type = INSN_NOP; } + if (mcount && !strcmp(insn->call_dest->name, "__fentry__")) { + if (reloc) { + reloc->type = R_NONE; + elf_write_reloc(file->elf, reloc); + } + + elf_write_insn(file->elf, insn->sec, + insn->offset, insn->len, + arch_nop_insn(insn->len)); + + insn->type = INSN_NOP; + + list_add_tail(&insn->mcount_loc_node, + &file->mcount_loc_list); + } + /* * Whatever stack impact regular CALLs have, should be undone * by the RETURN of the called function. @@ -2791,6 +2866,7 @@ int check(const char *_objname, bool orc) INIT_LIST_HEAD(&file.insn_list); hash_init(file.insn_hash); + INIT_LIST_HEAD(&file.mcount_loc_list); file.c_file = !vmlinux && find_section_by_name(file.elf, ".comment"); file.ignore_unreachables = no_unreachable; file.hints = false; @@ -2838,6 +2914,13 @@ int check(const char *_objname, bool orc) warnings += ret; } + if (mcount) { + ret = create_mcount_loc_sections(&file); + if (ret < 0) + goto out; + warnings += ret; + } + if (orc) { ret = create_orc(&file); if (ret < 0) diff --git a/tools/objtool/check.h b/tools/objtool/check.h index 061aa96e15d3..b62afd3d970b 100644 --- a/tools/objtool/check.h +++ b/tools/objtool/check.h @@ -22,6 +22,7 @@ struct insn_state { struct instruction { struct list_head list; struct hlist_node hash; + struct list_head mcount_loc_node; struct section *sec; unsigned long offset; unsigned int len; diff --git a/tools/objtool/objtool.h b/tools/objtool/objtool.h index 528028a66816..427806079540 100644 --- a/tools/objtool/objtool.h +++ b/tools/objtool/objtool.h @@ -16,6 +16,7 @@ struct objtool_file { struct elf *elf; struct list_head insn_list; DECLARE_HASHTABLE(insn_hash, 20); + struct list_head mcount_loc_list; bool ignore_unreachables, c_file, hints, rodata; };