linux-kernel - Re: Re: [PATCH] perf probe: Fix failure to probe events on arm

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]

Message-ID: <5581355B.3010906@hitachi.com>
Date:	Wed, 17 Jun 2015 17:52:43 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	hekuang <hekuang@...o.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	He Kuang <hekuang@...wei.com>
CC:	a.p.zijlstra@...llo.nl, mingo@...hat.com, namhyung@...nel.org,
	wangnan0@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] perf probe: Fix failure to probe events on arm

On 2015/06/17 0:26, hekuang wrote:
> hi, Arnaldo
> 
> On 06/15/2015 10:49 PM, Arnaldo Carvalho de Melo wrote:
>> Em Mon, Jun 15, 2015 at 08:06:53AM +0000, He Kuang escreveu:
>>> Fix failure to probe events on arm, problem is introduced by commit
>>> 5a51fcd1f30c ("perf probe: Skip kernel symbols which is out of
>>> .text"). For some architectures, label '_etext' is not in the .text
>>> section(in .notes section for arm/arm64). Label out of .text section is
>>> not loaded as symbols and we got a zero value when look up its address,
>>> which causes all events be wrongly skiped.
>>>
>>> This patch uses kernel map->end when failed to get the address of
>>> '_etext' and fixes the problem.
>> Masami, can't we always use map->end then? Can you please take a look at
>> this patch and ack/nack it?
>>
>> - Arnaldo
> 
> I think _etext is more accurate than kernel map->end, because
> __map_groups__fixup_end() is called at the end of
> dso__load_sym(), which fixes map->end to next_map->start.
> 
> Comparative result as this:
>    etext_addr=ffffffff819a1b85, map->end=ffffffff81ff1000.
> 
> So if possible, we should use _etext.

Hmm, this seems to have another problem. If etext_addr != map->end,
we can't relay on that. Is there any good way to get the ".text"
address range from symbol map? Until we find it, I'd rather like to
skip checking text address range on arm, because it looks meaningless :(

Thank you,

> 
> Thanks.
>>   
>>> Problem can be reproduced on arm as following:
>>>
>>>    # perf probe --add='generic_perform_write'
>>>    generic_perform_write+0 is out of .text, skip it.
>>>    Probe point 'generic_perform_write' not found.
>>>      Error: Failed to add events. Reason: No such file or directory (Code: -2)
>>>
>>> After this patch:
>>>
>>>    # perf probe --add='generic_perform_write'
>>>    Added new event:
>>>      probe:generic_perform_write (on generic_perform_write)
>>>
>>>    You can now use it in all perf tools, such as:
>>>
>>>      perf record -e probe:generic_perform_write -aR sleep 1
>>>
>>> Signed-off-by: He Kuang <hekuang@...wei.com>
>>> ---
>>>   tools/perf/util/probe-event.c | 16 +++++++++++++++-
>>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>>> index daa24a2..ee26961 100644
>>> --- a/tools/perf/util/probe-event.c
>>> +++ b/tools/perf/util/probe-event.c
>>> @@ -575,8 +575,22 @@ static int post_process_probe_trace_events(struct probe_trace_event *tevs,
>>>   		pr_warning("Relocated base symbol is not found!\n");
>>>   		return -EINVAL;
>>>   	}
>>> -	/* Get the address of _etext for checking non-probable text symbol */
>>> +	/* Get the address of _etext for checking non-probable text symbol,
>>> +	   for some architectures (e.g. arm, arm64), _etext is out of .text
>>> +	   section and not loaded as symbols, use kernel map->end instead.
>>> +	 */
>>>   	etext_addr = kernel_get_symbol_address_by_name("_etext", false);
>>> +	if (etext_addr == 0) {
>>> +		struct map *map;
>>> +
>>> +		map = kernel_get_module_map(NULL);
>>> +		if (!map) {
>>> +			pr_err("Failed to get a map for kernel\n");
>>> +			return -EINVAL;
>>> +		}
>>> +
>>> +		etext_addr = map->end;
>>> +	}
>>>   
>>>   	for (i = 0; i < ntevs; i++) {
>>>   		if (tevs[i].point.address && !tevs[i].point.retprobe) {
>>> -- 
>>> 1.8.5.2
>> --
>> 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/
>>
> 
> 
> --
> 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/
> 


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@...achi.com
--
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/