linux-kernel - Re: [PATCH v1 1/4] perf parse-events: Remove BPF event support

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:   Mon, 23 Oct 2023 10:01:33 +0100
From:   Quentin Monnet <quentin@...valent.com>
To:     Manu Bretelle <chantr4@...il.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Ian Rogers <irogers@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>, Fangrui Song <maskray@...gle.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Andi Kleen <ak@...ux.intel.com>, Leo Yan <leo.yan@...aro.org>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Carsten Haitzler <carsten.haitzler@....com>,
        Ravi Bangoria <ravi.bangoria@....com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
        Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Yang Jihong <yangjihong1@...wei.com>,
        James Clark <james.clark@....com>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Eduard Zingerman <eddyz87@...il.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Yonghong Song <yhs@...com>, Rob Herring <robh@...nel.org>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        bpf@...r.kernel.org, llvm@...ts.linux.dev,
        Wang Nan <wangnan0@...wei.com>,
        Wang ShaoBo <bobo.shaobowang@...wei.com>,
        YueHaibing <yuehaibing@...wei.com>,
        He Kuang <hekuang@...wei.com>,
        Brendan Gregg <brendan.d.gregg@...il.com>
Subject: Re: [PATCH v1 1/4] perf parse-events: Remove BPF event support

On 20/10/2023 23:37, Manu Bretelle wrote:
> On Fri, Oct 20, 2023 at 05:39:25PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Oct 19, 2023 at 03:48:56PM -0700, Manu Bretelle escreveu:
>>> On Thu, Oct 19, 2023 at 06:08:33PM -0300, Arnaldo Carvalho de Melo wrote:
>>>> I wonder how to improve the current situation to detect these kinds of
>>>> problems in the future, i.e. how to notice that some file needed by some
>>>> Makefile, etc got removed or that some feature test fails because some
>>>> change in the test .c files makes them fail and thus activates fallbacks
>>>> like the one above :-\
>>  
>>> I think it is tricky. Specifically to this situation, some CI could try to build
>>> the different combinaison of bpftool and check the features through the build
>>> `bpftool --version`.
>>
>> Right, if the right packages are installed, we expect to get some
>> bpftool build output, if that changes after some patch, flag it.

Correct, this is what we do on the CI on the GitHub mirror (checking
that the mirrored version builds correctly, with the expected features).

>>
>> Does bpftool have something like:
>>
>> ⬢[acme@...lbox perf-tools-next]$ perf version --build-options
>> perf version 6.6.rc1.ga8dd62d05e56
>>                  dwarf: [ on  ]  # HAVE_DWARF_SUPPORT
>>     dwarf_getlocations: [ on  ]  # HAVE_DWARF_GETLOCATIONS_SUPPORT
>>          syscall_table: [ on  ]  # HAVE_SYSCALL_TABLE_SUPPORT
>>                 libbfd: [ OFF ]  # HAVE_LIBBFD_SUPPORT
>>             debuginfod: [ on  ]  # HAVE_DEBUGINFOD_SUPPORT
>>                 libelf: [ on  ]  # HAVE_LIBELF_SUPPORT
>>                libnuma: [ on  ]  # HAVE_LIBNUMA_SUPPORT
>> numa_num_possible_cpus: [ on  ]  # HAVE_LIBNUMA_SUPPORT
>>                libperl: [ on  ]  # HAVE_LIBPERL_SUPPORT
>>              libpython: [ on  ]  # HAVE_LIBPYTHON_SUPPORT
>>               libslang: [ on  ]  # HAVE_SLANG_SUPPORT
>>              libcrypto: [ on  ]  # HAVE_LIBCRYPTO_SUPPORT
>>              libunwind: [ on  ]  # HAVE_LIBUNWIND_SUPPORT
>>     libdw-dwarf-unwind: [ on  ]  # HAVE_DWARF_SUPPORT
>>                   zlib: [ on  ]  # HAVE_ZLIB_SUPPORT
>>                   lzma: [ on  ]  # HAVE_LZMA_SUPPORT
>>              get_cpuid: [ on  ]  # HAVE_AUXTRACE_SUPPORT
>>                    bpf: [ on  ]  # HAVE_LIBBPF_SUPPORT
>>                    aio: [ on  ]  # HAVE_AIO_SUPPORT
>>                   zstd: [ on  ]  # HAVE_ZSTD_SUPPORT
>>                libpfm4: [ on  ]  # HAVE_LIBPFM
>>          libtraceevent: [ on  ]  # HAVE_LIBTRACEEVENT
>>          bpf_skeletons: [ on  ]  # HAVE_BPF_SKEL
>> ⬢[acme@...lbox perf-tools-next]$
>>
>> ?
>>
> 
> It has
> 
>     $ ./tools/bpf/bpftool/bpftool --version -j | jq .features
>     {
>       "libbfd": false,
>       "llvm": true,
>       "skeletons": true,
>       "bootstrap": false
>     }
> 
> 
> Maybe Quentin knows of something else.

This, or ldd on the binary (unless it was a static build). But "bpftool
version" should be enough to tell whether the LLVM disassembler is built
in or not, so we haven't needed something else so far.

Quentin