[PATCH bpf-next v2 0/8] tools build: bpf: Append EXTRA_CFLAGS and HOST_EXTRACFLAGS

[PATCH bpf-next v2 0/8] tools build: bpf: Append EXTRA_CFLAGS and HOST_EXTRACFLAGS

[Leo Yan]

Append EXTRA_CFLAGS and HOST_EXTRACFLAGS to the BPF build.

This mitigates an issue introduced in GCC 15, where a {0} initializer
does not guarantee zeroing the entire union [1].

The common changes under tools to support EXTRA_CFLAGS and
HOST_EXTRACFLAGS are sent separately [2].  As suggested, BPF patches
would be picked up via the bpf tree, so this series only includes BPF
related changes.

Verification on bpf-ci (with tools changes [2]:

  https://github.com/kernel-patches/bpf/actions/runs/26815163486

[1] https://gcc.gnu.org/gcc-15/changes.html
[2] https://lore.kernel.org/all/20260602-tools_build_fix_zero_init-v7-0-631baf679fe7@arm.com/

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes in v2:
- Used strscpy() instead in patch 06 (Ihor).
- Added prefix "bpf-next" in subject (Alexei).
- Added patch 01 to pass host cflags to bootstrap libbpf.
- Added patch 08 to avoid static LLVM linking for cross build.
- Link to v1: https://lore.kernel.org/r/20260323-tools_build_fix_zero_init_bpf_only-v1-0-d1cfad2f4cd1@arm.com

---
Leo Yan (8):
      bpftool: Pass host flags to bootstrap libbpf
      bpftool: Avoid adding EXTRA_CFLAGS to HOST_CFLAGS
      bpftool: Append extra host flags
      libbpf: Initialize CFLAGS before including Makefile.include
      tools/bpf: build: Append extra cflags
      selftests/bpf: Initialize operation name before use
      selftests/bpf: Use common CFLAGS for urandom_read
      selftests/bpf: Avoid static LLVM linking for cross builds

 tools/bpf/Makefile                                    |  1 +
 tools/bpf/bpftool/Makefile                            | 15 ++++++++++++---
 tools/lib/bpf/Makefile                                | 17 +++++++++--------
 tools/testing/selftests/bpf/Makefile                  | 19 +++++++++++++------
 tools/testing/selftests/bpf/prog_tests/verifier_log.c |  1 +
 5 files changed, 36 insertions(+), 17 deletions(-)
---
base-commit: b93c55b4932dd7e32dca8cf34a3443cc87a02906
change-id: 20260323-tools_build_fix_zero_init_bpf_only-52232f62fb7f

Best regards,
-- 
Leo Yan <leo.yan@arm.com>

[PATCH bpf-next v2 1/8] bpftool: Pass host flags to bootstrap libbpf

[Leo Yan]

bpftool builds a bootstrap libbpf with HOSTCC, but the libbpf submake can
still inherit target build flags through CFLAGS. This can break cross
builds when host objects are compiled with target-only options.

Since HOST_CFLAGS contains warning options that are not suitable for
building libbpf, use LIBBPF_BOOTSTRAP_CFLAGS with the warning options
removed to build the bootstrap libbpf. Clear EXTRA_CFLAGS so target
extra flags are not mixed into the host bootstrap libbpf build.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/bpf/bpftool/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 0febf60e1b64656035dfe93cd15cba090015587a..1f033e578f90a2d6b93168ab41399de758bdf659 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -47,7 +47,8 @@ $(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_HDRS_
 $(LIBBPF_BOOTSTRAP): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_BOOTSTRAP_OUTPUT)
 	$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_BOOTSTRAP_OUTPUT) \
 		DESTDIR=$(LIBBPF_BOOTSTRAP_DESTDIR:/=) prefix= \
-		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" $@ install_headers
+		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" \
+		CFLAGS="$(LIBBPF_BOOTSTRAP_CFLAGS)" EXTRA_CFLAGS= $@ install_headers
 
 $(LIBBPF_BOOTSTRAP_INTERNAL_HDRS): $(LIBBPF_BOOTSTRAP_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_BOOTSTRAP_HDRS_DIR)
 	$(call QUIET_INSTALL, $@)
@@ -92,6 +93,9 @@ HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
 		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
 HOST_LDFLAGS := $(LDFLAGS)
 
+# Remove warnings for libbpf bootstrap build
+LIBBPF_BOOTSTRAP_CFLAGS := $(filter-out -W -Wall -Wextra -Wformat -Wformat-signedness,$(HOST_CFLAGS))
+
 INSTALL ?= install
 RM ?= rm -f
 

-- 
2.34.1

Re: [PATCH bpf-next v2 1/8] bpftool: Pass host flags to bootstrap libbpf

[Quentin Monnet]

2026-06-02 15:47 UTC+0100 ~ Leo Yan <leo.yan@arm.com>
> bpftool builds a bootstrap libbpf with HOSTCC, but the libbpf submake can
> still inherit target build flags through CFLAGS. This can break cross
> builds when host objects are compiled with target-only options.
> 
> Since HOST_CFLAGS contains warning options that are not suitable for
> building libbpf, use LIBBPF_BOOTSTRAP_CFLAGS with the warning options
> removed to build the bootstrap libbpf. Clear EXTRA_CFLAGS so target
> extra flags are not mixed into the host bootstrap libbpf build.
> 
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>  tools/bpf/bpftool/Makefile | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 0febf60e1b64656035dfe93cd15cba090015587a..1f033e578f90a2d6b93168ab41399de758bdf659 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -47,7 +47,8 @@ $(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_HDRS_
>  $(LIBBPF_BOOTSTRAP): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_BOOTSTRAP_OUTPUT)
>  	$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_BOOTSTRAP_OUTPUT) \
>  		DESTDIR=$(LIBBPF_BOOTSTRAP_DESTDIR:/=) prefix= \
> -		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" $@ install_headers
> +		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" \
> +		CFLAGS="$(LIBBPF_BOOTSTRAP_CFLAGS)" EXTRA_CFLAGS= $@ install_headers
>  
>  $(LIBBPF_BOOTSTRAP_INTERNAL_HDRS): $(LIBBPF_BOOTSTRAP_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_BOOTSTRAP_HDRS_DIR)
>  	$(call QUIET_INSTALL, $@)
> @@ -92,6 +93,9 @@ HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
>  		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
>  HOST_LDFLAGS := $(LDFLAGS)
>  
> +# Remove warnings for libbpf bootstrap build

Nitpick: We could expand this comment to briefly explain why. Not sure
it's worth a respin, though.

> +LIBBPF_BOOTSTRAP_CFLAGS := $(filter-out -W -Wall -Wextra -Wformat -Wformat-signedness,$(HOST_CFLAGS))

Do we need to remove all warnings, or would it be sufficient to take out
-Wformat and -Wformat-signedness? I don't mind removing them all if
necessary, just asking.

Acked-by: Quentin Monnet <qmo@kernel.org>

Thanks!

[PATCH bpf-next v2 2/8] bpftool: Avoid adding EXTRA_CFLAGS to HOST_CFLAGS

[Leo Yan]

Prepare for future changes where EXTRA_CFLAGS may include flags not
applicable to the host compiler.

Move the HOST_CFLAGS assignment before appending EXTRA_CFLAGS to
CFLAGS so that HOST_CFLAGS does not inherit flags from EXTRA_CFLAGS.

Acked-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/bpf/bpftool/Makefile | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 1f033e578f90a2d6b93168ab41399de758bdf659..616c14247e4bb690e16ae4ff8c1992e6d4fc863e 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -82,6 +82,12 @@ CFLAGS += -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ \
 ifneq ($(BPFTOOL_VERSION),)
 CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"'
 endif
+
+# This must be done before appending EXTRA_CFLAGS to CFLAGS to avoid
+# including flags that are not applicable to the host compiler.
+HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
+		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
+
 ifneq ($(EXTRA_CFLAGS),)
 CFLAGS += $(EXTRA_CFLAGS)
 endif
@@ -89,8 +95,6 @@ ifneq ($(EXTRA_LDFLAGS),)
 LDFLAGS += $(EXTRA_LDFLAGS)
 endif
 
-HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
-		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
 HOST_LDFLAGS := $(LDFLAGS)
 
 # Remove warnings for libbpf bootstrap build

-- 
2.34.1

[PATCH bpf-next v2 3/8] bpftool: Append extra host flags

[Leo Yan]

Append HOST_EXTRACFLAGS to HOST_CFLAGS so that additional flags can be
applied to the host compiler.

Acked-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/bpf/bpftool/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 616c14247e4bb690e16ae4ff8c1992e6d4fc863e..96be5647f0e1370247025d65e813db376b146e52 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -87,6 +87,7 @@ endif
 # including flags that are not applicable to the host compiler.
 HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
 		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
+HOST_CFLAGS += $(HOST_EXTRACFLAGS)
 
 ifneq ($(EXTRA_CFLAGS),)
 CFLAGS += $(EXTRA_CFLAGS)

-- 
2.34.1

[PATCH bpf-next v2 4/8] libbpf: Initialize CFLAGS before including Makefile.include

[Leo Yan]

tools/scripts/Makefile.include may expand EXTRA_CFLAGS in a future
change.  This could alter the initialization of CFLAGS, as the default
options "-g -O2" would never be set once EXTRA_CFLAGS is expanded.

Prepare for this by moving the CFLAGS initialization before including
tools/scripts/Makefile.include, so it is not affected by the extended
EXTRA_CFLAGS.

Append EXTRA_CFLAGS to CFLAGS only after including Makefile.include and
place it last so that the extra flags propagate properly and can
override the default options.

tools/scripts/Makefile.include already appends $(CLANG_CROSS_FLAGS) to
CFLAGS, the Makefile appends $(CLANG_CROSS_FLAGS) again, remove the
redundant append.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
---
 tools/lib/bpf/Makefile | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 168140f8e6461bd06db40e23d21a3fb8847ccbf4..eca584fb061e16013e76827e4203f6be0477a73e 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -49,6 +49,14 @@ man_dir_SQ = '$(subst ','\'',$(man_dir))'
 export man_dir man_dir_SQ INSTALL
 export DESTDIR DESTDIR_SQ
 
+# Defer assigning EXTRA_CFLAGS to CFLAGS until after including
+# tools/scripts/Makefile.include, as it may add flags to EXTRA_CFLAGS.
+ifdef EXTRA_CFLAGS
+  CFLAGS :=
+else
+  CFLAGS := -g -O2
+endif
+
 include $(srctree)/tools/scripts/Makefile.include
 
 # copy a bit from Linux kbuild
@@ -70,13 +78,6 @@ LIB_TARGET	= libbpf.a libbpf.so.$(LIBBPF_VERSION)
 LIB_FILE	= libbpf.a libbpf.so*
 PC_FILE		= libbpf.pc
 
-# Set compile option CFLAGS
-ifdef EXTRA_CFLAGS
-  CFLAGS := $(EXTRA_CFLAGS)
-else
-  CFLAGS := -g -O2
-endif
-
 # Append required CFLAGS
 override CFLAGS += -std=gnu89
 override CFLAGS += $(EXTRA_WARNINGS) -Wno-switch-enum
@@ -84,7 +85,7 @@ override CFLAGS += -Werror -Wall
 override CFLAGS += $(INCLUDES)
 override CFLAGS += -fvisibility=hidden
 override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-override CFLAGS += $(CLANG_CROSS_FLAGS)
+override CFLAGS += $(EXTRA_CFLAGS)
 
 # flags specific for shared library
 SHLIB_FLAGS := -DSHARED -fPIC

-- 
2.34.1

Re: [PATCH bpf-next v2 4/8] libbpf: Initialize CFLAGS before including Makefile.include

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removal of `override CFLAGS += $(CLANG_CROSS_FLAGS)` breaks Clang cross-compilation when `CFLAGS` is overridden on the command line.
--

commit 6aa5adddfad905f5f29ccfe28312c5a00d2d1082
Author: Leo Yan <leo.yan@arm.com>

libbpf: Initialize CFLAGS before including Makefile.include

This commit reorders CFLAGS initialization to happen before including
Makefile.include so it is not affected by expanded EXTRA_CFLAGS. It also
removes the appending of CLANG_CROSS_FLAGS, citing redundancy with the
include file.

> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 168140f8e6461..eca584fb061e1 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile

[ ... ]

> @@ -84,7 +85,7 @@ override CFLAGS += -Werror -Wall
>  override CFLAGS += $(INCLUDES)
>  override CFLAGS += -fvisibility=hidden
>  override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -override CFLAGS += $(CLANG_CROSS_FLAGS)
> +override CFLAGS += $(EXTRA_CFLAGS)

[Severity: Medium]
Does removing this override directive break Clang cross-compilation when
CFLAGS is overridden on the command line?

While tools/scripts/Makefile.include already appends $(CLANG_CROSS_FLAGS),
it uses a standard assignment. According to GNU Make semantics, standard
assignments are ignored if a variable is overridden via the command line
(e.g., make CFLAGS="-O3").

By removing the override directive here, the build system might fail to
unconditionally append cross-compilation flags (like --target= and
--sysroot=), causing Clang to fall back to compiling for the host
architecture instead of the intended target.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-tools_build_fix_zero_init_bpf_only-v2-0-c76e5250ea1c@arm.com?part=4

[PATCH bpf-next v2 5/8] tools/bpf: build: Append extra cflags

[Leo Yan]

Append EXTRA_CFLAGS to CFLAGS so that additional flags can be applied to
the compiler.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/bpf/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index fd2585af1252669c59228af3a77320e449e1a1ab..9c19e81f3c274767c3b9b94c907cbbe3ce9fe78c 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -11,6 +11,7 @@ INSTALL ?= install
 CFLAGS += -Wall -O2
 CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/tools/include/uapi \
 	  -I$(srctree)/tools/include
+CFLAGS += $(EXTRA_CFLAGS)
 
 # This will work when bpf is built in tools env. where srctree
 # isn't set and when invoked from selftests build, where srctree

-- 
2.34.1

Re: [PATCH bpf-next v2 5/8] tools/bpf: build: Append extra cflags

[Ihor Solodrai]

On 6/2/26 7:47 AM, Leo Yan wrote:
> Append EXTRA_CFLAGS to CFLAGS so that additional flags can be applied to
> the compiler.
> 
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>  tools/bpf/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
> index fd2585af1252669c59228af3a77320e449e1a1ab..9c19e81f3c274767c3b9b94c907cbbe3ce9fe78c 100644
> --- a/tools/bpf/Makefile
> +++ b/tools/bpf/Makefile
> @@ -11,6 +11,7 @@ INSTALL ?= install
>  CFLAGS += -Wall -O2
>  CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/tools/include/uapi \
>  	  -I$(srctree)/tools/include
> +CFLAGS += $(EXTRA_CFLAGS)

Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>

>  
>  # This will work when bpf is built in tools env. where srctree
>  # isn't set and when invoked from selftests build, where srctree
> 

[PATCH bpf-next v2 6/8] selftests/bpf: Initialize operation name before use

[Leo Yan]

ASAN reports stack-buffer-overflow due to the uninitialized op_name.

Initialize it to fix the issue.

Fixes: 054b6c7866c7 ("selftests/bpf: Add verifier log tests for BPF_BTF_LOAD command")
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/testing/selftests/bpf/prog_tests/verifier_log.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/verifier_log.c b/tools/testing/selftests/bpf/prog_tests/verifier_log.c
index c01c0114af1b7476d27885ce380d90400a4bdc89..4542bb586d723b8fda2faf8261066f16102c60c0 100644
--- a/tools/testing/selftests/bpf/prog_tests/verifier_log.c
+++ b/tools/testing/selftests/bpf/prog_tests/verifier_log.c
@@ -317,6 +317,7 @@ static void verif_btf_log_subtest(bool bad_btf)
 	res = load_btf(&opts, true);
 	ASSERT_EQ(res, -ENOSPC, "half_log_fd");
 	ASSERT_EQ(strlen(logs.buf), 24, "log_fixed_25");
+	strscpy(op_name, "log_fixed", sizeof(op_name));
 	ASSERT_STRNEQ(logs.buf, logs.reference, 24, op_name);
 
 	/* validate rolling verifier log logic: try all variations of log buf

-- 
2.34.1

Re: [PATCH bpf-next v2 6/8] selftests/bpf: Initialize operation name before use

[Ihor Solodrai]

On 6/2/26 7:47 AM, Leo Yan wrote:
> ASAN reports stack-buffer-overflow due to the uninitialized op_name.
> 
> Initialize it to fix the issue.
> 
> Fixes: 054b6c7866c7 ("selftests/bpf: Add verifier log tests for BPF_BTF_LOAD command")
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>  tools/testing/selftests/bpf/prog_tests/verifier_log.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/verifier_log.c b/tools/testing/selftests/bpf/prog_tests/verifier_log.c
> index c01c0114af1b7476d27885ce380d90400a4bdc89..4542bb586d723b8fda2faf8261066f16102c60c0 100644
> --- a/tools/testing/selftests/bpf/prog_tests/verifier_log.c
> +++ b/tools/testing/selftests/bpf/prog_tests/verifier_log.c
> @@ -317,6 +317,7 @@ static void verif_btf_log_subtest(bool bad_btf)
>  	res = load_btf(&opts, true);
>  	ASSERT_EQ(res, -ENOSPC, "half_log_fd");
>  	ASSERT_EQ(strlen(logs.buf), 24, "log_fixed_25");
> +	strscpy(op_name, "log_fixed", sizeof(op_name));

Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>

>  	ASSERT_STRNEQ(logs.buf, logs.reference, 24, op_name);
>  
>  	/* validate rolling verifier log logic: try all variations of log buf
> 

[PATCH bpf-next v2 7/8] selftests/bpf: Use common CFLAGS for urandom_read

[Leo Yan]

The urandom_read helper and its shared library are built with $(CLANG)
directly rather than through the normal selftest $(CC) rules.

The CFLAGS variable can contain specific flags only for $(CC) but might
be imcompatible for $(CLANG) and those flags are not necessarily valid
for the clang-only urandom_read build.

Split the BPF selftest local flags into COMMON_CFLAGS and append them to
CFLAGS for the normal build path. Use COMMON_CFLAGS directly for
urandom_read and liburandom_read.so, while still filtering out -static as
before.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/testing/selftests/bpf/Makefile | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index bc049620c7745ce35976f5e0922eb680e38def13..1e47e29ba4214925c62afc0595a7edb859ace944 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -51,7 +51,7 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
 endif
 
-CFLAGS += -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
+COMMON_CFLAGS = -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
 	  -Wall -Werror -fno-omit-frame-pointer				\
 	  -Wno-unused-but-set-variable					\
 	  $(GENFLAGS) $(SAN_CFLAGS) $(LIBELF_CFLAGS)			\
@@ -64,7 +64,7 @@ LDLIBS += $(LIBELF_LIBS) -lz -lrt -lpthread
 PCAP_CFLAGS	:= $(shell $(PKG_CONFIG) --cflags libpcap 2>/dev/null && echo "-DTRAFFIC_MONITOR=1")
 PCAP_LIBS	:= $(shell $(PKG_CONFIG) --libs libpcap 2>/dev/null)
 LDLIBS += $(PCAP_LIBS)
-CFLAGS += $(PCAP_CFLAGS)
+CFLAGS += $(COMMON_CFLAGS) $(PCAP_CFLAGS)
 
 # Some utility functions use LLVM libraries
 jit_disasm_helpers.c-CFLAGS = $(LLVM_CFLAGS)
@@ -261,7 +261,7 @@ endif
 $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom_read.map
 	$(call msg,LIB,,$@)
 	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
-		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
+		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) \
 		     $(filter %.c,$^) $(filter-out -static,$(LDLIBS)) \
 		     -Wno-unused-command-line-argument \
 		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
@@ -271,7 +271,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
 $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
 	$(call msg,BINARY,,$@)
 	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
-		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
+		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
 		     -Wno-unused-command-line-argument \
 		     -lurandom_read $(filter-out -static,$(LDLIBS)) -L$(OUTPUT) \
 		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \

-- 
2.34.1

Re: [PATCH bpf-next v2 7/8] selftests/bpf: Use common CFLAGS for urandom_read

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 3246 bytes --]

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index bc049620c774..1e47e29ba421 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -51,7 +51,7 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
>  srctree := $(patsubst %/,%,$(dir $(srctree)))
>  endif
>
> -CFLAGS += -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
> +COMMON_CFLAGS = -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
>  	  -Wall -Werror -fno-omit-frame-pointer				\
>  	  -Wno-unused-but-set-variable					\
>  	  $(GENFLAGS) $(SAN_CFLAGS) $(LIBELF_CFLAGS)			\
> @@ -64,7 +64,7 @@ LDLIBS += $(LIBELF_LIBS) -lz -lrt -lpthread
>  PCAP_CFLAGS	:= $(shell $(PKG_CONFIG) --cflags libpcap 2>/dev/null && echo "-DTRAFFIC_MONITOR=1")
>  PCAP_LIBS	:= $(shell $(PKG_CONFIG) --libs libpcap 2>/dev/null)
>  LDLIBS += $(PCAP_LIBS)
> -CFLAGS += $(PCAP_CFLAGS)
> +CFLAGS += $(COMMON_CFLAGS) $(PCAP_CFLAGS)

Ian Rogers raised a concern in v4 that COMMON_CFLAGS is being assigned
before 'include ../lib.mk' (which happens later around line 165).

The ../lib.mk include appends important flags to CFLAGS, such as
-D_GNU_SOURCE=. Since COMMON_CFLAGS uses recursive assignment (=), these
flags added by lib.mk should be available when COMMON_CFLAGS expands.
However, COMMON_CFLAGS references $(GENFLAGS), $(SAN_CFLAGS), and
$(LIBELF_CFLAGS) which are defined before lib.mk, but lib.mk may also
modify CFLAGS directly with additional flags.

Will urandom_read miss any flags that lib.mk adds to CFLAGS but that
aren't captured in the variables referenced by COMMON_CFLAGS? Ian
suggested moving these assignments below the include to ensure all
lib.mk-added flags are captured.

Reference:
https://lore.kernel.org/all/CAP-5=fXjd15e5YpCM9KMjEhpjLxvxc6qUk0g7BprCfkzcRZ5_g@mail.gmail.com/

>
>  # Some utility functions use LLVM libraries
>  jit_disasm_helpers.c-CFLAGS = $(LLVM_CFLAGS)

[ ... ]

> @@ -261,7 +261,7 @@ endif
>  $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom_read.map
>  	$(call msg,LIB,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) \
>  		     $(filter %.c,$^) $(filter-out -static,$(LDLIBS)) \
>  		     -Wno-unused-command-line-argument \
>  		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \

[ ... ]

> @@ -271,7 +271,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
>  $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
>  	$(call msg,BINARY,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
>  		     -Wno-unused-command-line-argument \
>  		     -lurandom_read $(filter-out -static,$(LDLIBS)) -L$(OUTPUT) \
>  		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26828477669

Re: [PATCH bpf-next v2 7/8] selftests/bpf: Use common CFLAGS for urandom_read

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Replacing CFLAGS with COMMON_CFLAGS for urandom_read breaks cross-compilation with Clang.
--

commit 537d69efefb1121c195758d9362eba3f31c54f36
Author: Leo Yan <leo.yan@arm.com>

selftests/bpf: Use common CFLAGS for urandom_read

This commit introduces a COMMON_CFLAGS variable to separate general flags
from CC-specific ones that might be incompatible with CLANG when building
urandom_read and its shared library.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index bc049620c7745..1e47e29ba4214 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -51,7 +51,7 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
>  srctree := $(patsubst %/,%,$(dir $(srctree)))
>  endif
>  
> -CFLAGS += -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
> +COMMON_CFLAGS = -g $(OPT_FLAGS) -rdynamic -std=gnu11				\

[Severity: Low]
Does this change break cross-compilation with Clang?

By defining COMMON_CFLAGS from scratch without including the pre-existing
CFLAGS, this drops any earlier contents from the urandom_read build.
This strips CLANG_CROSS_FLAGS (which is appended to CFLAGS earlier by
tools/scripts/Makefile.include), depriving Clang of essential
cross-compilation arguments like --sysroot and --gcc-toolchain.

Does this also inadvertently ignore any user-provided CFLAGS?

[ ... ]

> @@ -261,7 +261,7 @@ endif
>  $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom_read.map
>  	$(call msg,LIB,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) \

[Severity: Low]
When replacing CFLAGS with COMMON_CFLAGS here for the shared library build,
does this remove the required sysroot and toolchain cross-compilation flags?

[ ... ]

> @@ -271,7 +271,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
>  $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
>  	$(call msg,BINARY,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \

[Severity: Low]
Similarly, does the urandom_read build rule also lose these required
cross-compilation flags when using COMMON_CFLAGS?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-tools_build_fix_zero_init_bpf_only-v2-0-c76e5250ea1c@arm.com?part=7

Re: [PATCH bpf-next v2 7/8] selftests/bpf: Use common CFLAGS for urandom_read

[Ihor Solodrai]

On 6/2/26 10:25 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Replacing CFLAGS with COMMON_CFLAGS for urandom_read breaks cross-compilation with Clang.
> --
> 
> commit 537d69efefb1121c195758d9362eba3f31c54f36
> Author: Leo Yan <leo.yan@arm.com>
> 
> selftests/bpf: Use common CFLAGS for urandom_read
> 
> This commit introduces a COMMON_CFLAGS variable to separate general flags
> from CC-specific ones that might be incompatible with CLANG when building
> urandom_read and its shared library.
> 
>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>> index bc049620c7745..1e47e29ba4214 100644
>> --- a/tools/testing/selftests/bpf/Makefile
>> +++ b/tools/testing/selftests/bpf/Makefile
>> @@ -51,7 +51,7 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
>>  srctree := $(patsubst %/,%,$(dir $(srctree)))
>>  endif
>>  
>> -CFLAGS += -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
>> +COMMON_CFLAGS = -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
> 
> [Severity: Low]
> Does this change break cross-compilation with Clang?

Please check this, looks plausible.

> 
> By defining COMMON_CFLAGS from scratch without including the pre-existing
> CFLAGS, this drops any earlier contents from the urandom_read build.
> This strips CLANG_CROSS_FLAGS (which is appended to CFLAGS earlier by
> tools/scripts/Makefile.include), depriving Clang of essential
> cross-compilation arguments like --sysroot and --gcc-toolchain.
> 
> Does this also inadvertently ignore any user-provided CFLAGS?
> 
> [ ... ]
> 
>> @@ -261,7 +261,7 @@ endif
>>  $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom_read.map
>>  	$(call msg,LIB,,$@)
>>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
>> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
>> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) \
> 
> [Severity: Low]
> When replacing CFLAGS with COMMON_CFLAGS here for the shared library build,
> does this remove the required sysroot and toolchain cross-compilation flags?
> 
> [ ... ]
> 
>> @@ -271,7 +271,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
>>  $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
>>  	$(call msg,BINARY,,$@)
>>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
>> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
>> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
> 
> [Severity: Low]
> Similarly, does the urandom_read build rule also lose these required
> cross-compilation flags when using COMMON_CFLAGS?
> 

[PATCH bpf-next v2 8/8] selftests/bpf: Avoid static LLVM linking for cross builds

[Leo Yan]

The BPF selftests prefer static LLVM linking, which works for native
builds but can break cross builds. Its --link-static output may include
host-only libraries that are unavailable for the cross compilation,
causing link failures.

Avoid static LLVM linking for cross builds and use shared LLVM libraries
instead. Native builds keep the existing behavior.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/testing/selftests/bpf/Makefile | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 1e47e29ba4214925c62afc0595a7edb859ace944..ffa90674e86f639d3a9cadb833e57f3693d77bdc 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -188,8 +188,15 @@ ifeq ($(feature-llvm),1)
   LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
   # both llvm-config and lib.mk add -D_GNU_SOURCE, which ends up as conflict
   LLVM_CFLAGS  += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
-  # Prefer linking statically if it's available, otherwise fallback to shared
-  ifeq ($(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo static),static)
+  # Cross compilation must use dynamic linking to avoid unresolved library
+  # dependencies. For native build, prefer linking statically if it's
+  # available, otherwise fallback to shared.
+  ifneq ($(ARCH), $(HOSTARCH))
+    LLVM_LINK_STATIC :=
+  else
+    LLVM_LINK_STATIC := $(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo y)
+  endif
+  ifeq ($(LLVM_LINK_STATIC),y)
     LLVM_LDLIBS  += $(shell $(LLVM_CONFIG) --link-static --libs $(LLVM_CONFIG_LIB_COMPONENTS))
     LLVM_LDLIBS  += $(filter-out -lxml2,$(shell $(LLVM_CONFIG) --link-static --system-libs $(LLVM_CONFIG_LIB_COMPONENTS)))
     LLVM_LDLIBS  += -lstdc++

-- 
2.34.1

Re: [PATCH bpf-next v2 8/8] selftests/bpf: Avoid static LLVM linking for cross builds

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Flawed native vs cross-build detection using un-normalized `ARCH` against normalized `HOSTARCH`.
--

commit 9a32865094dbf702cf09a9de14d120a1f3ca8a92
Author: Leo Yan <leo.yan@arm.com>

selftests/bpf: Avoid static LLVM linking for cross builds

This commit modifies the BPF selftests Makefile to avoid static LLVM linking
during cross builds. It intends to use dynamic linking for cross compilation
while preserving the existing preference for static linking on native builds.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 1e47e29ba4214..ffa90674e86f6 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -188,8 +188,15 @@ ifeq ($(feature-llvm),1)
>    LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
>    # both llvm-config and lib.mk add -D_GNU_SOURCE, which ends up as conflict
>    LLVM_CFLAGS  += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
> -  # Prefer linking statically if it's available, otherwise fallback to shared
> -  ifeq ($(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo static),static)
> +  # Cross compilation must use dynamic linking to avoid unresolved library
> +  # dependencies. For native build, prefer linking statically if it's
> +  # available, otherwise fallback to shared.
> +  ifneq ($(ARCH), $(HOSTARCH))

[Severity: Medium]
Will this comparison accurately identify native builds?

The kernel build system normalizes $(HOSTARCH) (for example, "x86_64" becomes
"x86"), but $(ARCH) might retain the un-normalized string if passed from the
environment or top-level Makefile.

If $(ARCH) is "x86_64" and $(HOSTARCH) is "x86", this check evaluates to true
even on a native build, unintentionally forcing shared LLVM libraries instead
of keeping the static linking behavior as intended.

Would it be more robust to compare $(SRCARCH) to $(HOSTARCH), or to check if
$(CROSS_COMPILE) is empty instead?

> +    LLVM_LINK_STATIC :=
> +  else
> +    LLVM_LINK_STATIC := $(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo y)
> +  endif
> +  ifeq ($(LLVM_LINK_STATIC),y)
>      LLVM_LDLIBS  += $(shell $(LLVM_CONFIG) --link-static --libs $(LLVM_CONFIG_LIB_COMPONENTS))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-tools_build_fix_zero_init_bpf_only-v2-0-c76e5250ea1c@arm.com?part=8