linux-kernel - Re: [linux-next-20250324]/tool/bpf/bpftool fails to complie on linux-next-20250324

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: <a5cccd3a-ff63-4adc-aec1-ad61a58a4b25@kernel.org>
Date: Tue, 25 Mar 2025 15:27:34 +0000
From: Quentin Monnet <qmo@...nel.org>
To: Tomas Glozar <tglozar@...hat.com>
Cc: Saket Kumar Bhaskar <skb99@...ux.ibm.com>,
 Venkat Rao Bagalkote <venkat88@...ux.ibm.com>,
 Hari Bathini <hbathini@...ux.ibm.com>, bpf <bpf@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, linuxppc-dev@...ts.ozlabs.org,
 jkacur@...hat.com, lgoncalv@...hat.com, gmonaco@...hat.com,
 williams@...hat.com, rostedt@...dmis.org
Subject: Re: [linux-next-20250324]/tool/bpf/bpftool fails to complie on
 linux-next-20250324

> My commits sets BPFTOOL to bpftool since otherwise, the feature check
> would fail, as BPFTOOL wouldn't be defined, since it is not passed to
> the feature detection make call.


Sorry I don't understand the issue, why not simply rename the variable
that you introduced in tools/build/feature/Makefile at the same time, as
well? That should solve it, no? This way you don't have to export it
from the rtla Makefiles. Or am I missing something?


2025-03-25 16:09 UTC+0100 ~ Tomas Glozar <tglozar@...hat.com>
> út 25. 3. 2025 v 15:59 odesílatel Tomas Glozar <tglozar@...hat.com> napsal:
>> Shouldn't the selftests always test the in-tree bpftool instead of the
>> system one? Let's say there is a stray BPFTOOL environmental variable.
>> In that case, the tests will give incorrect, possibly false negative
>> results, if the user is expecting selftests to test what is in the
>> kernel tree. If it is intended to also be able to test with another


I think this was the intent.


>> version of bpftool, we can work around the problem by removing the
>> BPFTOOL definition from tools/scripts/Makefile.include and exporting
>> it from the rtla Makefiles instead, to make sure the feature tests see
>> it. The problem with that is, obviously, that future users of the
>> bpftool feature check would have to do the same, or they would always
>> fail, unless the user sets BPFTOOL as an environment variable
>> themselves.
> 
> Or the selftests and other users could use another variable, like
> BPFTOOL_TEST or BPFTOOL_INTERNAL. Not sure what you BPF folks think
> about that. I believe assuming BPFTOOL refers to the system bpftool
> (just like it does for all the other tools) is quite reasonable.


The variable name needs to change either for rtla + probe, or for all
BPF utilities relying on it, indeed. As far as I can see, this is the
sched_ext and runqslower utilities as well as the selftests for bpf,
sched_ext, and hid. I'd argue that the variable has been in use in the
Makefiles for these tools and selftests for a while, and renaming it
might produce errors for anyone already using it to pass a specfic
version of bpftool to try.


> The reason why I opted to use the system bpftool is that bpftool
> itself has a lot of dependencies


Note: Not that many dependencies, most of them are optional. For
bootstrap bpftool we pass -lelf, -lz, sometimes -lzstd.

Quentin