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: <15370998-6a91-464d-b680-931074889bc1@kernel.org>
Date: Tue, 25 Mar 2025 12:04:23 +0000
From: Quentin Monnet <qmo@...nel.org>
To: Saket Kumar Bhaskar <skb99@...ux.ibm.com>
Cc: 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, tglozar@...hat.com, rostedt@...dmis.org
Subject: Re: [linux-next-20250324]/tool/bpf/bpftool fails to complie on
 linux-next-20250324

2025-03-25 17:14 UTC+0530 ~ Saket Kumar Bhaskar <skb99@...ux.ibm.com>
> On Tue, Mar 25, 2025 at 11:09:24AM +0000, Quentin Monnet wrote:
>> 2025-03-25 16:02 UTC+0530 ~ Venkat Rao Bagalkote <venkat88@...ux.ibm.com>
>>> Greetings!!!
>>>
>>>
>>> bpftool fails to complie on linux-next-20250324 repo.
>>>
>>>
>>> Error:
>>>
>>> make: *** No rule to make target 'bpftool', needed by '/home/linux/
>>> tools/testing/selftests/bpf/tools/include/vmlinux.h'. Stop.
>>> make: *** Waiting for unfinished jobs.....
>>
>>
>> Thanks! Would be great to have a bit more context on the error (and on
>> how to reproduce) for next time. Bpftool itself seems to compile fine,
>> the error shows that it's building it from the context of the selftests
>> that seems broken.
>>
>>
> Yes, selftest build for BPF fails.
> ## pwd
> /linux/tools/testing/selftests/bpf
> 
> # make -j 33
> 
> make: *** No rule to make target 'bpftool', needed by '/home/upstreamci/linux/tools/testing/selftests/bpf/tools/include/vmlinux.h'.  Stop.
> make: *** Waiting for unfinished jobs....
> 
>>> Git bisect points to commit: 8a635c3856ddb74ed3fe7c856b271cdfeb65f293 as
>>> first bad commit.
>>
>> Thank you Venkat for the bisect!
>>
>> On a quick look, that commit introduced a definition for BPFTOOL in
>> tools/scripts/Makefile.include:
>>
>> 	diff --git a/tools/scripts/Makefile.include .../Makefile.include
>> 	index 0aa4005017c7..71bbe52721b3 100644
>> 	--- a/tools/scripts/Makefile.include
>> 	+++ b/tools/scripts/Makefile.include
>> 	@@ -91,6 +91,9 @@ LLVM_CONFIG	?= llvm-config
>> 	 LLVM_OBJCOPY	?= llvm-objcopy
>> 	 LLVM_STRIP	?= llvm-strip
>> 	
>> 	+# Some tools require bpftool
>> 	+BPFTOOL		?= bpftool
>> 	+
>> 	 ifeq ($(CC_NO_CLANG), 1)
>> 	 EXTRA_WARNINGS += -Wstrict-aliasing=3
>>
>> But several utilities or selftests under tools/ include
>> tools/scripts/Makefile.include _and_ use their own version of the
>> $(BPFTOOL) variable, often assigning only if unset, for example in
>> tools/testing/selftests/bpf/Makefile:
>>
>> 	BPFTOOL ?= $(DEFAULT_BPFTOOL)
>>
>> My guess is that the new definition from Makefile.include overrides this
>> with simply "bpftool" as a value, and the Makefile fails to build it as
>> a result.
>>
>> If I guessed correctly, one workaround would be to rename the variable
>> in Makefile.include (and in whatever Makefile now relies on it) into
>> something that is not used in the other Makefiles, for example
>> BPFTOOL_BINARY.
>>
>> Please copy the BPF mailing list on changes impacting BPF tooling (or
>> for BPF-related patchsets in general).
>>
>> Thanks,
>> Quentin
> Yes you are right that the new definition from Makefile.include overrides this
> with simply "bpftool" as a value, and the Makefile in bpf selftest fails to 
> build it as a result.
> 
> But the main cause is that it is not able to locate the bpftool binary.

I'm not sure I follow. What component is not able to locate the binary?

If you talk about the BPF selftests, I believe they only fail to locate
it because of the collision on the $(BPFTOOL) variable. Selftests'
Makefile was able to find the binary before that commit, so there should
be no need to change the path to the binary.

If you talk about tools/tracing/rtla/Makefile failing to locate bpftool,
it's another matter. As far as I understand, the RTLA Makefile assumes
that bpftool is available from $PATH, this is why the commit introduced
a probe in tools/build/feature: to ensure that bpftool is installed and
available. So here again, I don't see the motivation for changing the
path to the binary (And how do you know it's /usr/sbin/bpftool anyway?
Some users have it under /usr/local/sbin/, for example). If the intent
were to compile a bootstrap bpftool to make sure that it's available
instead then it should replicate what other BPF utilities or selftests
do, and get rid of the probe. But the commit description for
8a635c3856dd indicates that RTLA folks prefer not to compile bpftool and
rely on it being installed.

Quentin