[PATCHSET v2 0/5] perf tools: Fix /proc/kallsyms map split

[Namhyung Kim <namhyung@kernel.org>]

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.

* v2 changes)
 - use map__kmaps()  (Ian)
 - use temporary root directory  (Ian)
 - Add Ian's Reviewed-by

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/kallsyms-split.c | 156 ++++++++++++++++++++++++++++++
 tools/perf/tests/tests.h          |   1 +
 tools/perf/util/symbol.c          |  16 ++-
 5 files changed, 171 insertions(+), 4 deletions(-)
 create mode 100644 tools/perf/tests/kallsyms-split.c

-- 
2.52.0.158.g65b55ccf14-goog