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-next>] [day] [month] [year] [list]
Message-ID: <1446803172-83107-1-git-send-email-wangnan0@huawei.com>
Date:	Fri, 6 Nov 2015 09:46:12 +0000
From:	Wang Nan <wangnan0@...wei.com>
To:	<acme@...nel.org>, <namhyung@...nel.org>
CC:	<lizefan@...wei.com>, <pi3orama@....com>,
	<linux-kernel@...r.kernel.org>, <jolsa@...nel.org>,
	<masami.hiramatsu.pt@...achi.com>, Wang Nan <wangnan0@...wei.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: [PATCH] perf tools: Rebuild rbtree when adjusting symbols for kcore

In dso__split_kallsyms_for_kcore(), current code adjusts symbol's
address but only reinsert it into rbtree if the symbol belongs to
another map. However, the expression for adjusting symbol (pos->start -=
curr_map->start - curr_map->pgoff) can change the relative order between
two symbols (even if the affected symbols are in different maps, in
kcore case they are possible to share one same dso), which damages the
rbtree.

For example:

When using kcore:

# readelf -a /proc/kcore

  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  ...
  LOAD           0x0000000000002000 0xffffffc000000000 0x0000000000000000    <-- kernel
                 0x000000007fc00000 0x000000007fc00000  RWE    1000
  LOAD           0xfffffffffc002000 0xffffffbffc000000 0x0000000000000000    <-- module
                 0x0000000004000000 0x0000000004000000  RWE    1000

For modules memory area:
  map->start = 0xffffffbffc000000, map->pgoff = 0xfffffffffc002000
For normal kernel memory area:
  map->start = 0xffffffc000000000, map->pgoff = 0x0000000000002000

Function A is a normal kernel function at:	0xffffffc00021b428.
Function B is a function in module at: 		0xffffffbffc000000.

&A > &B before calling dso__split_kallsyms_for_kcore(), and they are
already in the rbtree.

During dso__split_kallsyms_for_kcore(), when adjusting symbols using
 pos->start -= curr_map->start - curr_map->pgoff

pos->start for A become: (0xffffffc00021b428 - 0xffffffc000000000 + 0x0000000000002000) = 0x21d428
pos->start for B become: (0xffffffbffc000000 - 0xffffffbffc000000 + 0xfffffffffc002000) = 0xfffffffffc002000

&A < &B, the order is changed.

This patch rebuild rbtree unconditionally to ensure the rbtree is
always healthy.

Signed-off-by: Wang Nan <wangnan0@...wei.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Jiri Olsa <jolsa@...nel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc: Namhyung Kim <namhyung@...nel.org>
Cc: Zefan Li <lizefan@...wei.com>
Cc: pi3orama@....com
---

Here is my test result on my aarch64 system:

*Step 1: create kprobes*

[root@...alhost ~]# ./perf_arm64 probe -m /tmp/kernel_module.ko my_func
Added new event:
  probe:my_func (on my_func in kernel_module)

You can now use it in all perf tools, such as:

	perf record -e probe:my_func -aR sleep 1

[root@...alhost ~]# ./perf_arm64 probe sys_write
Added new event:
  probe:sys_write      (on sys_write)

You can now use it in all perf tools, such as:

	perf record -e probe:sys_write -aR sleep 1

[root@...alhost ~]# cat /sys/kernel/debug/kprobes/list 
ffffffbffc000000  k  my_func+0x0  kernel_module [DISABLED]
ffffffc00021b428  k  SyS_write+0x0    [DISABLED]


*Step 2: rebuild perf without commit 98d3b25*

$ git log --oneline
3321d2b Revert "perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success"
e054731 perf stat: Make stat options global
0014de1 perf sched latency: Fix thread pid reuse issue
98d3b25 perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success
956959f perf trace: Fix documentation for -i


*Step 3: test and get the buggy result*

[root@...alhost ~]# PAGER=cat ./perf_arm64 probe -l 
  Error: Failed to show event list.

[root@...alhost ~]# PAGER=cat ./perf_arm64 probe -v -l 
map_groups__set_modules_path_dir: cannot open /lib/modules/4.1.12+ dir
Problems setting modules path maps, continuing anyway...
Opening /sys/kernel/debug/tracing//kprobe_events write=0
Opening /sys/kernel/debug/tracing//uprobe_events write=0
Parsing probe_events: p:probe/my_func kernel_module:my_func
Group:probe Event:my_func probe:p
Looking at the vmlinux_path (7 entries long)
symsrc__init: cannot get elf header.
Using /proc/kcore for kernel object code
Using /proc/kallsyms for symbols
try to find information at 3ffc000000 in kernel_module
Failed to find module kernel_module.
Failed to find the path for kernel_module: [kernel_module]
Failed to find corresponding probes from debuginfo.
Failed to synthesize perf probe point: 0
  Error: Failed to show event list. Reason: Invalid argument (Code: -22)


*Step 4: Introduce this patch*

$ git log --oneline
36a8201 perf tools: Rebuild rbtree when adjusting symbols for kcore
3321d2b Revert "perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success"
e054731 perf stat: Make stat options global
0014de1 perf sched latency: Fix thread pid reuse issue
98d3b25 perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success


*Step 5: Try again*

[root@...alhost ~]# PAGER=cat ./perf_arm64 probe -l 
  probe:my_func (on my_func in kernel_module)
  probe:sys_write      (on sys_write)
[root@...alhost ~]# PAGER=cat ./perf_arm64 probe -v -l 
map_groups__set_modules_path_dir: cannot open /lib/modules/4.1.12+ dir
Problems setting modules path maps, continuing anyway...
Opening /sys/kernel/debug/tracing//kprobe_events write=0
Opening /sys/kernel/debug/tracing//uprobe_events write=0
Parsing probe_events: p:probe/my_func kernel_module:my_func
Group:probe Event:my_func probe:p
Looking at the vmlinux_path (7 entries long)
symsrc__init: cannot get elf header.
Using /proc/kcore for kernel object code
Using /proc/kallsyms for symbols
Failed to find corresponding probes from debuginfo.
Failed to find probe point from both of dwarf and map.
  probe:my_func (on my_func in kernel_module)
Parsing probe_events: p:probe/sys_write _text+1684520
Group:probe Event:sys_write probe:p
try to find information at 19b428 in kernel
Looking at the vmlinux_path (7 entries long)
symsrc__init: cannot get elf header.
Failed to find the path for kernel: Invalid ELF file
Failed to find corresponding probes from debuginfo.
  probe:sys_write      (on sys_write)

---
 tools/perf/util/symbol.c | 20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index b4cc766..09bb6e8 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -654,7 +654,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
 	struct map_groups *kmaps = map__kmaps(map);
 	struct map *curr_map;
 	struct symbol *pos;
-	int count = 0, moved = 0;
+	int count = 0;
 	struct rb_root *root = &dso->symbols[map->type];
 	struct rb_node *next = rb_first(root);
 
@@ -677,25 +677,23 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
 			rb_erase_init(&pos->rb_node, root);
 			symbol__delete(pos);
 		} else {
+			rb_erase_init(&pos->rb_node, root);
+
 			pos->start -= curr_map->start - curr_map->pgoff;
 			if (pos->end)
 				pos->end -= curr_map->start - curr_map->pgoff;
-			if (curr_map->dso != map->dso) {
-				rb_erase_init(&pos->rb_node, root);
-				symbols__insert(
-					&curr_map->dso->symbols[curr_map->type],
-					pos);
-				++moved;
-			} else {
-				++count;
-			}
+
+			symbols__insert(
+				&curr_map->dso->symbols[curr_map->type],
+				pos);
+			++count;
 		}
 	}
 
 	/* Symbols have been adjusted */
 	dso->adjust_symbols = 1;
 
-	return count + moved;
+	return count;
 }
 
 /*
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ