linux-kernel - Re: [PATCH] perf tools: Support bpf prologue for arm64

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] [day] [month] [year] [list]

Message-ID: <55E6D489.4060205@huawei.com>
Date:	Wed, 2 Sep 2015 18:50:49 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Will Deacon <will.deacon@....com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	Jean Pihet <jean.pihet@...aro.org>, He Kuang <hekuang@...wei.com>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] perf tools: Support bpf prologue for arm64



On 2015/9/2 18:34, Will Deacon wrote:
> On Mon, Aug 31, 2015 at 09:16:28PM +0100, Arnaldo Carvalho de Melo wrote:
>> Em Sat, Aug 29, 2015 at 03:16:52AM +0000, He Kuang escreveu:
>>> This patch implements arch_get_reg_info() for arm64 to enable
>>> HAVE_BPF_PROLOGUE feature. For arm64, structure pt_regs is not composed
>>> by fields of register names but an array of regs, so here we simply
>>> multiply fixed register size by index number to get the byte offset.
>> Hi Jean, Will, are you ok with this? Can I have Acked-by or Reviewed-by
>> tags from you?
> Any idea what this applies against? It's difficult to review it without
> knowing what PERF_HAVE_ARCH_GET_REG_INFO or HAVE_BPF_PROLOGUE are.
>
> Anyway, a couple of small comments below.
>
>> He, please try to add the authors of the files you change in the CC
>> list.
>>
>> - Arnaldo
>>   
>>> Signed-off-by: He Kuang <hekuang@...wei.com>
>>> ---
>>>   tools/perf/arch/arm64/Makefile          |  1 +
>>>   tools/perf/arch/arm64/util/dwarf-regs.c | 26 ++++++++++++++++++++++++++
>>>   2 files changed, 27 insertions(+)
> Any plan to do arch/arm/ too?
>
>>> diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
>>> index 7fbca17..1256e6e 100644
>>> --- a/tools/perf/arch/arm64/Makefile
>>> +++ b/tools/perf/arch/arm64/Makefile
>>> @@ -1,3 +1,4 @@
>>>   ifndef NO_DWARF
>>>   PERF_HAVE_DWARF_REGS := 1
>>>   endif
>>> +PERF_HAVE_ARCH_GET_REG_INFO := 1
>>> diff --git a/tools/perf/arch/arm64/util/dwarf-regs.c b/tools/perf/arch/arm64/util/dwarf-regs.c
>>> index d49efeb..cb2c50a 100644
>>> --- a/tools/perf/arch/arm64/util/dwarf-regs.c
>>> +++ b/tools/perf/arch/arm64/util/dwarf-regs.c
>>> @@ -10,6 +10,10 @@
>>>   
>>>   #include <stddef.h>
>>>   #include <dwarf-regs.h>
>>> +#include <string.h>
>>> +#include <linux/ptrace.h>
>>> +
>>> +#define PT_REG_SIZE (sizeof(((struct user_pt_regs *)0)->regs[0]))
> Why not add an "offset" field to pt_regs_dwarfnum and just calculate
> that using offsetof in the GPR_DWARFNUM_NAME macro?
>
>>>   
>>>   struct pt_regs_dwarfnum {
>>>   	const char *name;
>>> @@ -78,3 +82,25 @@ const char *get_arch_regstr(unsigned int n)
>>>   			return roff->name;
>>>   	return NULL;
>>>   }
>>> +
>>> +#ifdef HAVE_BPF_PROLOGUE
>>> +int arch_get_reg_info(const char *name, int *offset)
>>> +{
>>> +	const struct pt_regs_dwarfnum *roff;
>>> +
>>> +	if (!name || !offset)
>>> +		return -1;
>>> +
>>> +	for (roff = regdwarfnum_table; roff->name != NULL; roff++) {
>>> +		if (!strcmp(roff->name, name)) {
>>> +			if (roff->dwarfnum < 0)
> When is this ever true? Do we need up update REG_DWARFNUM_END to use
> a negative index?
>
> Will

Thank you for your review.

Yesterday Arnaldo gave some comment on corresponding function on x86_64,
please see discussion in following two threads:

http//lkml.kernel.org/n/20150831204328.GE2443@...hat.com
http://lkml.kernel.org/n/1441090789-108382-2-git-send-email-wangnan0@huawei.com

The conclusion is we should try out best to reuse kernel's 
regs_query_register_offset()
function, including providing same name and API and reusing its code. 
However,
we should avoid use it directly from kernel directory. Instead, we 
should copy them
to perf's directory.

Therefore, He Kuang needs to redo his work after a while.

Any suggestion about code reusing?

For ARM: I don't think this is a hard work. In fact we have tested our 
perf BPF code
on an ARM board. Haven't provided this because we haven't meet a real 
profiling task on
ARM which requires fetching argument from BPF program.

Thank you.

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