linux-kernel - Re: [PATCH v6 1/2] scripts: ftrace - move the sort-processing in ftrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211206151858.4d21a24d@gandalf.local.home>
Date:   Mon, 6 Dec 2021 15:18:58 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Yinan Liu <yinan@...ux.alibaba.com>
Cc:     peterz@...radead.org, mark-pk.tsai@...iatek.com, mingo@...hat.com,
        linux-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH v6 1/2] scripts: ftrace - move the sort-processing in
 ftrace_init

On Thu, 2 Dec 2021 12:58:00 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu,  2 Dec 2021 10:16:05 +0800
> Yinan Liu <yinan@...ux.alibaba.com> wrote:
> 
> > When the kernel starts, the initialization of ftrace takes
> > up a portion of the time (approximately 6~8ms) to sort mcount
> > addresses. We can save this time by moving mcount-sorting to
> > compile time.
> > 
> > Signed-off-by: Yinan Liu <yinan@...ux.alibaba.com>
> > Reported-by: kernel test robot <lkp@...el.com>  
> 
> After applying this, I get a failure on the kprobe self tests at boot up:
> 
>  Testing ftrace filter: OK
>  trace_kprobe: Testing kprobe tracing: 
>  trace_kprobe: Could not probe notrace function kprobe_trace_selftest_target
>  ------------[ cut here ]------------
>  WARNING: CPU: 2 PID: 1 at kernel/trace/trace_kprobe.c:1973 kprobe_trace_self_tests_init+0x5c/0x497
>  Modules linked in:

And I added the below patch, and it shows that the section is not properly
sorted. Something went wrong with your sorting.

I plan on keeping this check, at least as a compile option, to make sure
that the output is sorted, otherwise things will silently fail if they are
not.

This patch produced:

[    1.315419] ftrace: allocating 43510 entries in 170 pages
[    1.320638] ------------[ cut here ]------------
[    1.325227] [3] x86_pnpbios_disabled+0x0/0x1c at 8a51c707 is not sorted with __traceiter_initcall_level+0x0/0x60 at 87000660

I'm dropping the patches until this is "sorted out" :-)

-- Steve

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 9ca63df6553a..b112d00ba534 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6388,6 +6388,19 @@ static int ftrace_cmp_ips(const void *a, const void
*b) return 0;
 }
 
+static void test_is_sorted(unsigned long *start, unsigned long count)
+{
+	int i;
+
+	for (i = 1; i < count; i++) {
+		if (WARN(start[i - 1] > start[i],
+			 "[%d] %pS at %x is not sorted with %pS at %x\n",
i,
+			 (void *)start[i - 1], start[i - 1],
+			 (void *)start[i], start[i]))
+			break;
+	}
+}
+
 static int ftrace_process_locs(struct module *mod,
 			       unsigned long *start,
 			       unsigned long *end)
@@ -6414,6 +6427,8 @@ static int ftrace_process_locs(struct module *mod,
 	if (!IS_ENABLED(CONFIG_BUILDTIME_TABLE_SORT) || mod) {
 		sort(start, count, sizeof(*start),
 		     ftrace_cmp_ips, NULL);
+	} else {
+		test_is_sorted(start, count);
 	}
 
 	start_pg = ftrace_allocate_pages(count);