From: Nathan Chancellor <nathan@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
bpf <bpf@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Nicolas Schier <nicolas@fjasle.eu>,
Zheng Yejian <zhengyejian1@huawei.com>,
Martin Kelly <martin.kelly@crowdstrike.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [for-next][PATCH 4/6] scripts/sorttable: Zero out weak functions in mcount_loc table
Date: Tue, 25 Feb 2025 11:00:44 -0700 [thread overview]
Message-ID: <20250225180044.GA3655100@ax162> (raw)
In-Reply-To: <20250225104726.5e4eed32@gandalf.local.home>
On Tue, Feb 25, 2025 at 10:47:26AM -0500, Steven Rostedt wrote:
> On Mon, 24 Feb 2025 22:28:33 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > Thanks, I'm about to go to bed soon and I'll take a look more into it tomorrow.
>
> Can you try this patch (it has the clang fix too).
Yup, that appears to fix all my issues with my initial tests.
Tested-by: Nathan Chancellor <nathan@kernel.org>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 27c8def2139d..bec7b5dbdb3b 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -7004,7 +7004,6 @@ static int ftrace_process_locs(struct module *mod,
> unsigned long count;
> unsigned long *p;
> unsigned long addr;
> - unsigned long kaslr;
> unsigned long flags = 0; /* Shut up gcc */
> unsigned long pages;
> int ret = -ENOMEM;
> @@ -7056,25 +7055,37 @@ static int ftrace_process_locs(struct module *mod,
> ftrace_pages->next = start_pg;
> }
>
> - /* For zeroed locations that were shifted for core kernel */
> - kaslr = !mod ? kaslr_offset() : 0;
> -
> p = start;
> pg = start_pg;
> while (p < end) {
> unsigned long end_offset;
> - addr = ftrace_call_adjust(*p++);
> +
> + addr = *p++;
> +
> /*
> * Some architecture linkers will pad between
> * the different mcount_loc sections of different
> * object files to satisfy alignments.
> * Skip any NULL pointers.
> */
> - if (!addr || addr == kaslr) {
> + if (!addr) {
> + skipped++;
> + continue;
> + }
> +
> + /*
> + * If this is core kernel, make sure the address is in core
> + * or inittext, as weak functions get zeroed and KASLR can
> + * move them to something other than zero. It just will not
> + * move it to an area where kernel text is.
> + */
> + if (!mod && !(is_kernel_text(addr) || is_kernel_inittext(addr))) {
> skipped++;
> continue;
> }
>
> + addr = ftrace_call_adjust(addr);
> +
> end_offset = (pg->index+1) * sizeof(pg->records[0]);
> if (end_offset > PAGE_SIZE << pg->order) {
> /* We should have allocated enough */
> diff --git a/scripts/sorttable.c b/scripts/sorttable.c
> index 23c7e0e6c024..7b4b3714b1af 100644
> --- a/scripts/sorttable.c
> +++ b/scripts/sorttable.c
> @@ -611,13 +611,16 @@ static int add_field(uint64_t addr, uint64_t size)
> return 0;
> }
>
> +/* Used for when mcount/fentry is before the function entry */
> +static int before_func;
> +
> /* Only return match if the address lies inside the function size */
> static int cmp_func_addr(const void *K, const void *A)
> {
> uint64_t key = *(const uint64_t *)K;
> const struct func_info *a = A;
>
> - if (key < a->addr)
> + if (key + before_func < a->addr)
> return -1;
> return key >= a->addr + a->size;
> }
> @@ -827,9 +830,14 @@ static void *sort_mcount_loc(void *arg)
> pthread_exit(m_err);
> }
>
> - if (sort_reloc)
> + if (sort_reloc) {
> count = fill_relocs(vals, size, ehdr, emloc->start_mcount_loc);
> - else
> + /* gcc may use relocs to save the addresses, but clang does not. */
> + if (!count) {
> + count = fill_addrs(vals, size, start_loc);
> + sort_reloc = 0;
> + }
> + } else
> count = fill_addrs(vals, size, start_loc);
>
> if (count < 0) {
> @@ -1248,6 +1256,8 @@ static int do_file(char const *const fname, void *addr)
> #ifdef MCOUNT_SORT_ENABLED
> sort_reloc = true;
> rela_type = 0x403;
> + /* arm64 uses patchable function entry placing before function */
> + before_func = 8;
> #endif
> /* fallthrough */
> case EM_386:
next prev parent reply other threads:[~2025-02-25 18:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 15:18 [for-next][PATCH 0/6] ftrace: scripts/sorttable: Add arm64 and remove weak functions Steven Rostedt
2025-02-19 15:18 ` [for-next][PATCH 1/6] arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64 Steven Rostedt
2025-02-19 15:18 ` [for-next][PATCH 2/6] scripts/sorttable: Have mcount rela sort use direct values Steven Rostedt
2025-02-19 15:18 ` [for-next][PATCH 3/6] scripts/sorttable: Always use an array for the mcount_loc sorting Steven Rostedt
2025-02-19 15:18 ` [for-next][PATCH 4/6] scripts/sorttable: Zero out weak functions in mcount_loc table Steven Rostedt
2025-02-24 18:08 ` Nathan Chancellor
2025-02-24 18:15 ` Steven Rostedt
2025-02-25 2:56 ` Nathan Chancellor
2025-02-25 3:28 ` Steven Rostedt
2025-02-25 15:47 ` Steven Rostedt
2025-02-25 18:00 ` Nathan Chancellor [this message]
2025-02-19 15:18 ` [for-next][PATCH 5/6] ftrace: Update the mcount_loc check of skipped entries Steven Rostedt
2025-02-19 15:18 ` [for-next][PATCH 6/6] ftrace: Have ftrace pages output reflect freed pages Steven Rostedt
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=20250225180044.GA3655100@ax162 \
--to=nathan@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.kelly@crowdstrike.com \
--cc=masahiroy@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=zhengyejian1@huawei.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: 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