public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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:

  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