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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Nov 2022 11:58:29 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     James Clark <james.clark@....com>
Cc:     Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        German Gomez <german.gomez@....com>,
        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

Em Fri, Nov 18, 2022 at 11:32:43AM +0000, James Clark escreveu:
> 
> 
> 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.

I thought about doing it as a -U_FORTIFY_SOURCE but ended up doing it in
each test as I thought that way to be more robust, i.e. the way the
makefiles get that per-object CFLAGS and add to the global one could
flip and then this would break again.

But if people prefer it in the per-object file Build rule, np.

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