linux-kernel - Re: [PATCH perf/core 1/4] perf-probe: Fix to show correct locations for events on modules

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 11 Jan 2017 08:51:46 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: [PATCH perf/core 1/4] perf-probe: Fix to show correct locations
 for events on modules

On Tue, 10 Jan 2017 10:18:35 -0300
Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> Em Sat, Jan 07, 2017 at 02:25:09PM +0900, Masami Hiramatsu escreveu:
> > Fix to show correct locations for events on modules by
> > relocating given address. Currently the relocation is
> > done when we failed to find the address in debuginfo,
> > but for modules it always makes a mistakes.
> 
> Try to provide precise instructions on how to reproduce, for instance,
> here I'm not being able to reproduce:
> 
> [root@...et ~]# perf probe -m i915 chv_prepare_pll
> Added new event:
>   probe:chv_prepare_pll (on chv_prepare_pll in i915)
> 
> You can now use it in all perf tools, such as:
> 
> 	perf record -e probe:chv_prepare_pll -aR sleep 1
> 
> [root@...et ~]# perf probe -l
>   probe:chv_prepare_pll (on chv_prepare_pll in i915)
>   probe:e1000_xmit_frame (on e1000_get_link_up_info_80003es2lan:7@...el/e1000e/80003es2lan.c in e1000e)
> [root@...et ~]#
> 
> So it doesn't seem to "always make mistakes", what are the precise
> conditions to reproduce this problem?

OK, I found mymistakes. chv_prepare_pll in my i915 module is optimized
and have isra.X suffix, so perf ends up with searching it in map.
(That issue is fixed in [3/4] in this series as you may know)


This happens when the module text size is enough big, bigger than
sh_addr, because original code retries with given address + sh_addr
if it failed to find CU DIE at the given address. Any address smaller
than sh_addr always fails and it retries.

On my environment, the sh_addr of ".text" section is 0x10030. Since
i915 is a huge kernel module, we can see this issue as below.

$ grep "[Tt] .*\[i915\]" /proc/kallsyms | sort | head -n1
ffffffffc0270000 t i915_switcheroo_can_switch	[i915]

ffffffffc0270000 + 0x10030 = ffffffffc0280030, so we'll check
symbols cross this boundary.

$ grep "[Tt] .*\[i915\]" /proc/kallsyms | grep -B1 ^ffffffffc028  | head -n 2
ffffffffc027ff80 t haswell_init_clock_gating	[i915]
ffffffffc0280110 t valleyview_init_clock_gating	[i915]

So setup probes on both function and see what happen.

$ sudo ./perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
Added new events:
  probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
  probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)

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

	perf record -e probe:valleyview_init_clock_gating -aR sleep 1

$ sudo ./perf probe -l
  probe:haswell_init_clock_gating (on haswell_init_clock_gating@.../drm/i915/intel_pm.c in i915)
  probe:valleyview_init_clock_gating (on i915_vga_set_decode:4@.../drm/i915/i915_drv.c in i915)

As you can see, haswell_init_clock_gating is correctly shown, but
valleyview_init_clock_gating is not.

With this patch, both events shown correctly.

$ sudo ./perf probe -l
  probe:haswell_init_clock_gating (on haswell_init_clock_gating@.../drm/i915/intel_pm.c in i915)
  probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@.../drm/i915/intel_pm.c in i915)

I'll update patch description and resend with fix of [4/4].

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>