[lkml]   [2020]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectSubject: [PATCH] perf report: Fix arm64 gap between kernel start and module end
During execution of command 'perf report' in my arm64 virtual machine,
the error message is showed:

failed to process sample

__symbol__inc_addr_samples(860): ENOMEM! sym->name=__this_module,
start=0x1477100, addr=0x147dbd8, end=0x80002000, func: 0

The error is caused with path:
oe->deliver (ordered_events__deliver_event)
tool->sample (process_sample_event)
h = annotated_source__histogram(src, evidx) (NULL)

annotated_source__histogram failed is caused with path:
src->histograms = calloc(nr_hists, sizeof_sym_hist) (failed)

Calloc failed as the symbol__size(sym) is too huge. As show in error
message: start=0x1477100, end=0x80002000, size of symbol is about 2G.

This is the same problem as 'perf annotate: Fix s390 gap between kernel
end and module start (b9c0a64901d5bd)'. Perf gets symbol information from
/proc/kallsyms in __dso__load_kallsyms. A part of symbol in /proc/kallsyms
from my virtual machine is as follows:
#cat /proc/kallsyms | sort
ffff000001475080 d rpfilter_mt_reg [ip6t_rpfilter]
ffff000001475100 d $d [ip6t_rpfilter]
ffff000001475100 d __this_module [ip6t_rpfilter]
ffff000080080000 t _head
ffff000080080000 T _text
ffff000080080040 t pe_header

Take line 'ffff000001475100 d __this_module [ip6t_rpfilter]' as example.
The start and end of symbol are both set to ffff000001475100 in
dso__load_all_kallsyms. Then symbols__fixup_end will set the end of symbol
to next big address to ffff000001475100 in /proc/kallsyms, ffff000080080000
in this example. Then sizeof of symbol will be about 2G and cause the

The start of module in my machine is
ffff000000a62000 t $x [dm_mod]

The start of kernel in my machine is
ffff000080080000 t _head

There is a big gap between end of module and begin of kernel if a samll
amount of memory is used by module. And the last symbol in module will
have a large address range as caotaining the big gap.

Give that the module and kernel text segment sequence may change in
the future, fix this by limiting range of last symbol in module and kernel
to 4K in arch arm64.

Signed-off-by: Kemeng Shi <>
tools/perf/arch/arm64/util/Build | 1 +
tools/perf/arch/arm64/util/machine.c | 26 ++++++++++++++++++++++++++
2 files changed, 27 insertions(+)
create mode 100644 tools/perf/arch/arm64/util/machine.c

diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index 393b9895c..37cbfa5e9 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -2,6 +2,7 @@ libperf-y += header.o
libperf-y += tsc.o
libperf-y += sym-handling.o
libperf-y += kvm-stat.o
+libperf-y += machine.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
diff --git a/tools/perf/arch/arm64/util/machine.c b/tools/perf/arch/arm64/util/machine.c
new file mode 100644
index 000000000..a25be2431
--- /dev/null
+++ b/tools/perf/arch/arm64/util/machine.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <stdio.h>
+#include "debug.h"
+#include "symbol.h"
+/* On arm64, kernel text segment start at high memory address,
+ * for example 0xffff 0000 8xxx xxxx. Modules start at a low memory
+ * address, like 0xffff 0000 00ax xxxx. When only samll amount of
+ * memory is used by modules, gap between end of module's text segment
+ * and start of kernel text segment may be reach 2G.
+ * Therefore do not fill this gap and do not assign it to the kernel dso map.
+ */
+#define SYMBOL_LIMIT (1 << 12) /* 4K */
+void arch__symbols__fixup_end(struct symbol *p, struct symbol *c)
+ if ((strchr(p->name, '[') && strchr(c->name, '[') == NULL) ||
+ (strchr(p->name, '[') == NULL && strchr(c->name, '[')))
+ /* Limit range of last symbol in module and kernel */
+ p->end += SYMBOL_LIMIT;
+ else
+ p->end = c->start;
+ pr_debug4("%s sym:%s end:%#lx\n", __func__, p->name, p->end);
 \ /
  Last update: 2020-03-27 08:48    [W:0.040 / U:33.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site