linux-kernel - Re: [PATCH v2 10/10] perf tools: Move TUI-specific fields out of map

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:	Tue, 5 May 2015 11:22:31 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>
Subject: Re: [PATCH v2 10/10] perf tools: Move TUI-specific fields out of
 map_symbol

Em Tue, May 05, 2015 at 10:18:10AM +0900, Namhyung Kim escreveu:
> The has_children and unfolded fields don't belong to struct map_symbol
> since they're used by TUI only.  Move those fields out of map_symbol
> since the struct is also used by other places.
 
> This will also help to compact the sizeof struct hist_entry.
 
> Signed-off-by: Namhyung Kim <namhyung@...nel.org>
> Acked-by: Jiri Olsa <jolsa@...hat.com>

In a case like this, with changes, should we keep the Ack? I guess not, the fix
may introduce another problem, etc.

> fix segfault due to recursion in hist_entry__set_folding().

We will need a v3, this fixes the 'E'xpand segfault, but not the first
problem reported, again, this time step by step:

Samples: 1K of event 'cycles', Event count (approx.): 1597853394
  Children      Self  Command  Shared Object               Symbol
-   99.86%    99.86%  swapper  [kernel.vmlinux]            [k] cpu_startup_entry
   + cpu_startup_entry
+   90.17%     0.00%  swapper  [kernel.vmlinux]            [k] start_secondary
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] x86_64_start_kernel
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] x86_64_start_reservations
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] start_kernel
+    9.79%     0.00%  swapper  [kernel.vmlinux]            [k] rest_init
+    0.08%     0.00%  swapper  [kernel.vmlinux]            [k] thermal_interrupt

---------------------------------------

See the "+ cpu_startup_entry"? If I go there and press enter, I would expect to
see its callers, but what happens is:


Samples: 1K of event 'cycles', Event count (approx.): 1597853394
  Children      Self  Command  Shared Object               Symbol
+   99.86%    99.86%  swapper  [kernel.vmlinux]            [k] cpu_startup_entry
+   90.17%     0.00%  swapper  [kernel.vmlinux]            [k] start_secondary
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] x86_64_start_kernel
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] x86_64_start_reservations
+    9.79%     0.00%  swapper  [kernel.vmlinux].init.text  [k] start_kernel
+    9.79%     0.00%  swapper  [kernel.vmlinux]            [k] rest_init
+    0.08%     0.00%  swapper  [kernel.vmlinux]            [k] thermal_interrupt

---------------------------------------

It collapses the hist_entry instead of expanding it further.

I'm updating that branch, that now sits on top of what is in acme/perf/core.

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