[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251202081645.931527-1-namhyung@kernel.org>
Date: Tue, 2 Dec 2025 00:16:40 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>,
Ian Rogers <irogers@...gle.com>,
James Clark <james.clark@...aro.org>
Cc: Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org
Subject: [PATCHSET 0/5] perf tools: Fix /proc/kallsyms map split
Hello,
I found a weird bug in symbol handling for kallsyms. My system has a
live patch which is a module and it has some symbols that conflict
with the main kernel map.
For example, the symbols are common functions defined in the kernel
like kmalloc and kfree. They have 'u' type which is a unique global
symbol.
$ grep ' u ' /proc/kallsyms
ffffffff98798dd0 u kmalloc_caches [livepatch]
ffffffff97afb6c0 u kmalloc_trace_noprof [livepatch]
ffffffff9739e7a0 u __list_add_valid_or_report [livepatch]
ffffffff97afb240 u __kmalloc_noprof [livepatch]
ffffffff970597f0 u klp_enable_patch [livepatch]
ffffffff979939f0 u kfree [livepatch]
...
They are duplicate symbols and will be removed by the fixup routine.
But if symbol_conf.allow_aliases is set, they remain. This is the
case for perf lock contention, and it caused a trouble with the
kallsyms split code.
$ grep ' kfree' /proc/kallsyms
ffffffff97057a30 t kfree_rcu_shrink_scan
ffffffff97394380 T kfree_strarray
ffffffff9779b890 T kfree_skb_list_reason
ffffffff9787be60 t kfree_pmc
ffffffff979939f0 T kfree <<<--- here
ffffffff979bbc50 T kfree_skb_partial
ffffffff97a8f110 t kfree_rcu_work
ffffffff97a8f2f0 t kfree_rcu_monitor
ffffffff97a8f910 t kfree_rcu_shrink_count
ffffffff97af67f0 T kfree_const
ffffffff97afbbc0 T kfree_sensitive
ffffffff97b5c4a0 T kfree_link
ffffffff99255908 d kfree_rcu_shrinker
ffffffff998beec0 T kfree_rcu_scheduler_running
ffffffff979939f0 u kfree [livepatch] <<<--- duplicate
As the kfree function is in the livepatch module, any functions in the
main kernel map that come later than 'kfree' will now to be splitted.
This will create a lot of new kernel maps and loading them again will
go to the routines to load kallsyms and split. So the process was in
an infinite loop creating new maps and eventually gets killed.
I've added some defensive measures to prevent such situations and a
test case to verify it. But maybe we need to do something for 'u'
type symbols.
Thanks,
Namhyung
Namhyung Kim (5):
perf tools: Mark split kallsyms DSOs as loaded
perf tools: Fix split kallsyms DSO counting
perf tools: Fallback to initial kernel map properly
perf tools: Use machine->root_dir to find /proc/kallsyms
perf test: Add kallsyms split test
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 1 +
tools/perf/tests/fake_root/proc/kallsyms | 10 ++++
tools/perf/tests/fake_root/proc/modules | 1 +
tools/perf/tests/fake_root/proc/version | 1 +
tools/perf/tests/kallsyms-split.c | 72 ++++++++++++++++++++++++
tools/perf/tests/tests.h | 1 +
tools/perf/util/symbol.c | 16 ++++--
8 files changed, 99 insertions(+), 4 deletions(-)
create mode 100644 tools/perf/tests/fake_root/proc/kallsyms
create mode 100644 tools/perf/tests/fake_root/proc/modules
create mode 100644 tools/perf/tests/fake_root/proc/version
create mode 100644 tools/perf/tests/kallsyms-split.c
--
2.52.0.158.g65b55ccf14-goog
Powered by blists - more mailing lists