linux-kernel - Re: perf test unwind failing

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]

Date:	Fri, 27 Nov 2015 13:03:11 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	masami.hiramatsu.pt@...achi.com, David Ahern <dsahern@...il.com>
Subject: Re: perf test unwind failing

Em Fri, Nov 27, 2015 at 09:21:21AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 26, 2015 at 05:45:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > 	Can you take a look at 'perf test unwind'? It is failing in my
> > perf/core branch, no time to bisect that now.
> > 
> > [root@zoo ~]# perf test unwind
> > 40: Test dwarf unwind                                        : FAILED!
> 
> (gdb) set follow-fork-mode child
> (gdb) r test dwarf
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7fd2780 (LWP 29735)]
> 0x00000000004ac953 in map__kmap (map=map@...ry=0x7ffff7ffe4a0) at util/map.c:839
> 839             if (!map->dso || !map->dso->kernel) {
> (gdb) bt
> #0  0x00000000004ac953 in map__kmap (map=map@...ry=0x7ffff7ffe4a0) at util/map.c:839
> #1  0x00000000004a97a2 in machine__destroy_kernel_maps (machine=machine@...ry=0x7fffffffdb80) at util/machine.c:807
> #2  0x00000000004a9861 in machine__exit (machine=machine@...ry=0x7fffffffdb80) at util/machine.c:125
> #3  0x0000000000477669 in test__dwarf_unwind (subtest=<optimized out>) at tests/dwarf-unwind.c:197
> #4  0x000000000045a128 in run_test (test=test@...ry=0x888470 <arch_tests+80>, subtest=subtest@...ry=-1) at tests/builtin-test.c:241
> #5  0x000000000045a201 in test_and_print (t=t@...ry=0x888470 <arch_tests+80>, force_skip=force_skip@...ry=false, subtest=subtest@...ry=-1)
>     at tests/builtin-test.c:268
> #6  0x000000000045a42b in __cmd_test (argc=argc@...ry=1, argv=argv@...ry=0x7fffffffe3d0, skiplist=0x0) at tests/builtin-test.c:324
> #7  0x000000000045a707 in cmd_test (argc=1, argv=0x7fffffffe3d0, prefix=<optimized out>) at tests/builtin-test.c:416
> #8  0x00000000004782b0 in run_builtin (p=p@...ry=0x885d98 <commands+504>, argc=argc@...ry=2, argv=argv@...ry=0x7fffffffe3d0) at perf.c:387
> #9  0x00000000004784ad in handle_internal_command (argc=2, argv=0x7fffffffe3d0) at perf.c:448
> #10 0x0000000000478518 in run_argv (argcp=argcp@...ry=0x7fffffffe23c, argv=argv@...ry=0x7fffffffe230) at perf.c:492
> #11 0x0000000000478789 in main (argc=2, argv=0x7fffffffe3d0) at perf.c:609
> (gdb) q
> 
> 
> it's caused by following commit:
>   commit ebe9729c8c3171aa46ad5d7af40acdc29806689d
>   Author: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
>   Date:   Wed Nov 18 15:40:24 2015 +0900

Humm, affects just machine__exit(), how could it cause problems here?
 
> it kind of assumes that __machine__create_kernel_maps is called ono
> machine, but we don't do that in the tests/dwarf-unwind.c,

Must be some other patch (see below).

> only following initialization:
> 
>         machines__init(&machines);

Well, if you want to deal with a machine that supports a kernel, then
you need to create the kernel maps, if all you want to do is to deal
with userspace samples, why would you spend time on that?
 
>         machine = machines__find(&machines, HOST_KERNEL_ID);
>         if (!machine) {
>                 pr_err("Could not get machine\n");
>                 return -1;
>         }
> 
> 
> we could call machine__create_kernel_maps right here to fix the issue,
> (please check attached patch), but I wonder what's the proper interface
> we want to have for creating machine..

See above.

After reading the patch I see why you refer to that patch, it is just
that at machine__exit() one should free the kernel maps if they were
created, so it calls machine__destroy_kernel_maps(), and that will check
if the maps were allocated, if not, nothing will be done.

Anyway, I applied your patch, it fixes the problem, thanks!

- Arnaldo
--
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/