linux-kernel - Re: [PATCH 05/12] perf test: Add 'leafloop' test workload

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

Message-ID: <13f1a15c-b14f-b4cd-a523-2ec6df168224@arm.com>
Date:   Fri, 18 Nov 2022 11:32:43 +0000
From:   James Clark <james.clark@....com>
To:     Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        German Gomez <german.gomez@....com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-perf-users@...r.kernel.org, Leo Yan <leo.yan@...aro.org>,
        Zhengjun Xing <zhengjun.xing@...ux.intel.com>,
        Athira Jajeev <atrajeev@...ux.vnet.ibm.com>
Subject: Re: [PATCH 05/12] perf test: Add 'leafloop' test workload



On 17/11/2022 18:11, Namhyung Kim wrote:
> Hi,
> 
> On Thu, Nov 17, 2022 at 9:42 AM Ian Rogers <irogers@...gle.com> wrote:
>>
>> On Thu, Nov 17, 2022 at 9:24 AM Arnaldo Carvalho de Melo
>> <acme@...nel.org> wrote:
>>>
>>> Em Thu, Nov 17, 2022 at 09:16:58AM -0800, Ian Rogers escreveu:
>>>> On Thu, Nov 17, 2022 at 8:15 AM Arnaldo Carvalho de Melo
>>>> <acme@...nel.org> wrote:
>>>>>
>>>>> Em Thu, Nov 17, 2022 at 01:06:16PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>>>> Em Wed, Nov 16, 2022 at 03:38:47PM -0800, Namhyung Kim escreveu:
>>>>>>> The leafloop workload is to run an infinite loop in the test_leaf
>>>>>>> function.  This is needed for the ARM fp callgraph test to verify if it
>>>>>>> gets the correct callchains.
>>>>>>>
>>>>>>>   $ perf test -w leafloop
>>>>>>
>>>>>> On fedora:36
>>>>>>
>>>>>> In file included from /usr/include/bits/libc-header-start.h:33,
>>>>>>                  from /usr/include/stdlib.h:26,
>>>>>>                  from tests/workloads/leafloop.c:2:
>>>>>> /usr/include/features.h:412:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
>>>>>>   412 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
>>>>>>       |    ^~~~~~~
>>>>>> cc1: all warnings being treated as errors
>>>>>> make[5]: *** [/home/acme/git/perf/tools/build/Makefile.build:96: /tmp/build/perf/tests/workloads/leafloop.o] Error 1
>>>>>> make[5]: *** Waiting for unfinished jobs....
>>>>>>
>>>>>> I'll try removing the _FORTIFY_SOURCE
>>>>>
>>>>> Works after I added this to datasym.c, leafloop.c and brstack.c:
>>>>
>>>> Is there a reason we are compiling without -O ? Perhaps we can filter
>>>
>>> I assumed so as Namhyung added it, perhaps he is just carrying it from
>>> the pre-existing shell tests?
> 
> Exactly :)
> 
>>>
>>> I wonder its to have a predictable binary output that the test expects
>>> when doing things like hardware tracing? As it come from the coresight
>>> tests, IIRC.
> 
> I think it just checks frame-pointer based callstacks on ARM to have the
> precise results for leaves and their parents.
> 
> 
>>
>> Would the following in the Build be better:
>>
>> ```
>> # Undefine _FORTIFY_SOURCE as it doesn't work with -O0
>> CFLAGS_leafloop.o         = -g -O0 -fno-inline -fno-omit-frame-pointer
>> -U_FORTIFY_SOURCE
>> ```
>>
>> We could also use make's `filter-out`. If we are disabling inlining
>> then there is also `-fno-optimize-sibling-calls` otherwise we can
>> still lose stack frames.
> 
> I wonder if it's enough to use -O0 as it's enabled from -O2.
> Maybe we can get rid of -fno-inline as well.
> 
> German, did you have any concerns for those options?
> 

Is it possible to go with the -U_FORTIFY_SOURCE option? From looking at
the disassembly, changing -O and the other -f options makes quite a bit
of difference.

It's fairly important to that test because it's testing that the
combination of both frame pointer unwinding and dwarf unwinding result
in the complete stack.

If we change the options I'd have to go back and double check with
different compiler versions that it's still doing the right thing. For
example if a frame pointer is included for the last frame, then the
dwarf bit doesn't get tested.


> Thanks,
> Namhyung