linux-kernel - [ALMOST ready] Re: [PATCH 2/3] perf build: Use libtraceevent from the system

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]

Message-ID: <Y5ChXjt0uv/yDNwV@kernel.org>
Date:   Wed, 7 Dec 2022 11:21:18 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Ian Rogers <irogers@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>
Cc:     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>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        bpf@...r.kernel.org, Stephane Eranian <eranian@...gle.com>
Subject: [ALMOST ready] Re: [PATCH 2/3] perf build: Use libtraceevent from
 the system

Em Tue, Dec 06, 2022 at 02:22:15PM -0800, Ian Rogers escreveu:
> On Tue, Dec 6, 2022 at 9:31 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > Em Tue, Dec 06, 2022 at 02:13:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> > I'm missing some detail, this isn't working, util/trace-event.c is still
> > being built and linked.

> > The python binding should be usable without tracepoints, in fact its
> > first usage was just to have access to the perf metaevents, see
> > tools/perf/python/twatch.py.

> You're right. I'd assumed that if you were disabling libtraceevent
> then you'd also disable python. To fix the issue above you can do:

> --- a/tools/perf/util/python-ext-sources
> +++ b/tools/perf/util/python-ext-sources
> @@ -30,7 +30,6 @@ util/rblist.c
> util/counts.c
> util/print_binary.c
> util/strlist.c
> -util/trace-event.c
> ../lib/rbtree.c
> util/string.c
> util/symbol_fprintf.c

> but this needs making conditional (possibly in setup.py) on whether
> libtraceevent is present or not.

Ok, I fixed this by removing the util/trace-event.c file at setup.py
time, and removing it from the list of dependencies for python.so build,
etc.

With what I have at tmp.perf/core I'm being able to build with
combinations of:

- Having or not libtraceevent-devel installed

- Using NO_LIBTRACEEVENT=1

- The default build

All mixed up, but I wasn't so judicious so far, we need to add an entry
with NO_LIBTRACEVENT=1 to tools/perf/tests/, etc.

One thing I'm doing now is testing with the container builds, and I'm
afraid we have to delay deleting the in-kernel old copy of
tools/lib/traceevent till distros that don't ship libtraceevent as a
separate package are EOLed.

We need in those cases to fallback to tools/lib/traceevent/, with a
warning probably.

I'm now updating my container build recipes to install
libtraceevent-devel, when available, which isn't the case, for instance,
for almalinux:8, the first I tried updating.

Please take a look at:

https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf/core

The HEAD for that branch has the list of changes I made to get this
going.

Also I have the feeling the warning about libtraceevent not being
available should be made more proeminent and detailed in what gets
removed if this new, important dependency isn't met...

I agree removing libtraceevent and adding yet another dependency to
building perf is important since the libtraceevent maintainers took the
decision of having it moved away from the kernel sources, but since this
has been a no-brainer for so long, the fallout of this decision may be
noticeable.

At least by now we have clear markings of where libtraceevent is used.

Thanks,

- Arnaldo