linux-kernel - Re: [PATCH] perf record: Fixing record option data type in parse_branch

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:	Fri, 25 May 2012 10:44:27 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf record: Fixing record option data type in parse_branch_stack

Hi,

It should be something like that instead:

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 8a9687e..c9ca7c4 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -228,7 +228,7 @@ struct perf_record_opts {
        unsigned int freq;
        unsigned int mmap_pages;
        unsigned int user_freq;
-       int          branch_stack;
+       u64          branch_stack;
        u64          default_interval;
        u64          user_interval;
 };


On Fri, May 25, 2012 at 10:03 AM, Anshuman Khandual
<khandual@...ux.vnet.ibm.com> wrote:
> perf record: Fixing record option data type in parse_branch_stack
>
>        Currently parse_branch_stack does not update record.opts.branch_stack
>        value in powerpc architecture. opt->value is declared as int in struct
>        perf_record_opts. But is worked on as uint64_t isnide the function.
>        This breaks functionality in poweprc due to bit representation
>        of uint64_t which is inaccessible as int.
>
> Signed-off-by: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
> ---
>  tools/perf/builtin-record.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index e5cb084..161c0f1 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -677,7 +677,7 @@ parse_branch_stack(const struct option *opt, const char *str, int unset)
>         PERF_SAMPLE_BRANCH_KERNEL      |\
>         PERF_SAMPLE_BRANCH_HV)
>
> -       uint64_t *mode = (uint64_t *)opt->value;
> +       int *mode = (int *)opt->value;
>        const struct branch_mode *br;
>        char *s, *os = NULL, *p;
>        int ret = -1;
> --
> 1.7.9.5
>
>
>
> On Friday 25 May 2012 10:57 AM, Anshuman Khandual wrote:
>
>> This code is breaking in powerpc systems.
>>
>> (1) 'opt->value' gets updated inside the function parse_branch_stack via
>>     dereferencing a (uint64_t *) type casted pointer.
>>
>> (2) But the value is not accessible when we again use opt->value via
>>     dereferencing a (int *) type casted pointer.
>>
>> (3) As a result record.opts.branch_stack remains 0 and unchanged by parse_branch_stack
>>
>> This is caused by bit representation of 'uint64_t' and 'int' in powerpc systems. Bytes update
>> for the data (when accessed trough (uint64_t *) casting) is no longer available to the
>> data when accessed through (int *) type casting. Verified this from bit representation of
>> the data (accessed through both type casting methods).
>>
>> However this problem does not seem to be present on an Intel box. Integer dereferencing of
>> the opt->value still gives the value which was updated as (uint64_t).
>>
>> All this problem would not have been there if we had used (int *) instead of (uint64_t *) in
>> the first place inside parse_branch_stack function.
>>
>> On Thursday 24 May 2012 02:51 PM, Anshuman Khandual wrote:
>>
>>> Hey Stephane,
>>>
>>> Just wondering why we used the type casting of (uint64_t *) on a data
>>> which is defined as "int" in the structure of "perf_record_opts".
>>>
>>> struct perf_record_opts {
>>>         struct perf_target target;
>>>         bool         call_graph;
>>>         bool         group;
>>>         bool         inherit_stat;
>>>         bool         no_delay;
>>>         bool         no_inherit;
>>>         bool         no_samples;
>>>         bool         pipe_output;
>>>         bool         raw_samples;
>>>         bool         sample_address;
>>>         bool         sample_time;
>>>         bool         sample_id_all_missing;
>>>         bool         exclude_guest_missing;
>>>         bool         period;
>>>         unsigned int freq;
>>>         unsigned int mmap_pages;
>>>         unsigned int user_freq;
>>>         int          branch_stack;
>>>         u64          default_interval;
>>>         u64          user_interval;
>>> };
>>>
>>> static int
>>> parse_branch_stack(const struct option *opt, const char *str, int unset)
>>> {
>>> #define ONLY_PLM \
>>>         (PERF_SAMPLE_BRANCH_USER        |\
>>>          PERF_SAMPLE_BRANCH_KERNEL      |\
>>>          PERF_SAMPLE_BRANCH_HV)
>>>
>>>         uint64_t *mode = (uint64_t *)opt->value;
>>> --
>>> Regards
>>> Anshuman Khandual
>>>
>>> --
>>> 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/
>>
>
>
--
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/