All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Nan <wangnan0@huawei.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: <jolsa@redhat.com>, <acme@kernel.org>, <jolsa@kernel.org>,
	<mingo@redhat.com>, <lizefan@huawei.com>, <pi3orama@163.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6] perf: __kmod_path__parse: deal with kernel module names in '[]' correctly.
Date: Tue, 21 Apr 2015 17:28:51 +0800	[thread overview]
Message-ID: <55361853.60506@huawei.com> (raw)
In-Reply-To: <20150421051649.GA1905@sejong>

On 2015/4/21 13:16, Namhyung Kim wrote:
> Hi Wang,
> 
> On Tue, Apr 21, 2015 at 03:33:10AM +0000, Wang Nan wrote:
>> Before patch ba92732e9808df679ddf75c5ea1c0caae6d7dce2 ('perf kmaps:
>> Check kmaps to make code more robust'), perf report and perf annotate
>> will segfault if trace data contains kernel module information like
>> this:
>>
>>  # perf report -D -i ./perf.data
>>  ...
>>  0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffffffbff1018000(0xf068000) @ 0]: x [test_module]
>>  ...
>>
>>  # perf report -i ./perf.data --objdump=/path/to/objdump --kallsyms=/path/to/kallsyms
>>
>>  perf: Segmentation fault
>>  -------- backtrace --------
>>  /path/to/perf[0x503478]
>>  /lib64/libc.so.6(+0x3545f)[0x7fb201f3745f]
>>  /path/to/perf[0x499b56]
>>  /path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c]
>>  /path/to/perf(dso__load+0x72e)[0x49c21e]
>>  /path/to/perf(map__load+0x6e)[0x4ae9ee]
>>  /path/to/perf(thread__find_addr_map+0x24c)[0x47deec]
>>  /path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238]
>>  /path/to/perf[0x43ad02]
>>  /path/to/perf[0x4b55bc]
>>  /path/to/perf(ordered_events__flush+0xca)[0x4b57ea]
>>  /path/to/perf[0x4b1a01]
>>  /path/to/perf(perf_session__process_events+0x3be)[0x4b428e]
>>  /path/to/perf(cmd_report+0xf11)[0x43bfc1]
>>  /path/to/perf[0x474702]
>>  /path/to/perf(main+0x5f5)[0x42de95]
>>  /lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4]
>>  /path/to/perf[0x42dfc4]
>>
>> This is because __kmod_path__parse treats '[' leading names as kernel
>> name instead of names of kernel module. If perf.data contains build
>> information and the buildid of such modules can be found, the DSO of
>> it will be treated as kernel, not kernel module.
> 
> Sorry if I missed some prior discussion on it, but any chance to treat
> them as modules instead of kernel binaries?
> 
> Thanks,
> Namhyung
> 
> 

Sorry, I tried but failed to understand your question. What this patch do
is to treat them as modules instead of kernel binaries (or binary?
since kernel is a whole binary and kernel modules are DSOs).

[SNIP]

>> +	/* path            alloc_name  alloc_ext  kmod  comp   name             ext */
>> +	T("[test_module]", true      , true     , true, false, "[test_module]", NULL);
>> +	T("[test_module]", false     , true     , true, false, NULL           , NULL);
>> +	T("[test_module]", true      , false    , true, false, "[test_module]", NULL);
>> +	T("[test_module]", false     , false    , true, false, NULL           , NULL);
>> +	M("[test_module]", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
>> +	M("[test_module]", PERF_RECORD_MISC_KERNEL, true);
>> +	M("[test_module]", PERF_RECORD_MISC_USER, false);

Before this patch, these testcases will return kmod == false result.

Thanks.


  reply	other threads:[~2015-04-21  9:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21  3:33 [PATCH v6] perf: __kmod_path__parse: deal with kernel module names in '[]' correctly Wang Nan
2015-04-21  5:16 ` Namhyung Kim
2015-04-21  9:28   ` Wang Nan [this message]
2015-05-29  0:00     ` Namhyung Kim
2015-06-03  7:49       ` [PATCH v7] " Wang Nan
2015-06-03  8:47         ` Jiri Olsa
2015-06-03  8:52           ` [PATCH v8] " Wang Nan
2015-06-03  9:12             ` Jiri Olsa
2015-06-03 13:09               ` Arnaldo Carvalho de Melo
2015-06-04 14:12             ` [tip:perf/core] perf tools: Deal " tip-bot for Wang Nan
2015-05-28  8:33 ` [PATCH v6] perf: __kmod_path__parse: deal " Jiri Olsa
     [not found] <E1Yxs9m-0004lw-1t@feisty.vs19.net>
2015-05-28  7:31 ` Wangnan (F)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55361853.60506@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=pi3orama@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.