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]
Date:   Tue, 23 Nov 2021 11:41:41 +0000
From:   German Gomez <german.gomez@....com>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        acme@...nel.org, Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: [PATCH 1/1] perf arm-spe: extend Arm SPE test script with
 regression testing

Hi Leo,

Thanks for the comments.

On 23/11/2021 05:19, Leo Yan wrote:
> Hi German,
>
> On Fri, Nov 12, 2021 at 04:20:03PM +0000, German Gomez wrote:
>> Extend the test_arm_spe.sh script to test for regressions in the
>> decoding flow of Arm SPE samples. In order to support the tests, a set
>> of perf.data files has been generated offline and is being hosted under
>> tools/perf/tests/shell/test_arm_spe.tgz:
> Seems to me it's not a good idea to upstream perf data binaries into the
> mainline kernel.  I understood you want to test the perf data with
> different context tracing modes (using contextidr vs switch events),
> since these two different modes we cannot capture them with the same
> kernel Image, I think this is the main reason you upstreamed the perf
> data binaries in this patch.

For this patch I wanted to test the decoding of SPE events, given fixed
inputs, in order to lock the current implementation of the decoder.

>
> On the other hand, like CoreSight smoke testing, by default we can give
> priority for testing root PID namespace, so you could do the test with
> below commands, which is assumed that tracing PID in contextidr:
>
>   perf record -e arm_spe_0// -- test_program
>   perf report
>   perf script
>
> Then, for testing non-root PID namespace, can we use the command
> "unshare" to create a namespace and run perf tool in a non-root
> PID namespace?  In this way, you could record Arm SPE trace data and
> decode it on the fly.  Finally we can avoid to upstream perf data
> binaries.

I think adding additional smoke testing is a good idea. We could also
check if CONTEXTIDR is enabled in the config (either /boot/config... or
/proc/config.gz).


Thanks,
German

>
> Thanks,
> Leo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ