Re: [RFC PATCH v1 3/3] bpftool: Prefer zlib-rs over zlib when available

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpftool: link failure with pre-built libbpf.a when zlib-rs is used
--

commit 7a2cb794e37f624ded57767492091a08919fa52c
Author: Ian Rogers <irogers@google.com>

bpftool: Prefer zlib-rs over zlib when available

This commit updates the bpftool Makefile to detect and prefer zlib-rs over
C zlib, configuring ZLIB_CFLAGS and ZLIB_LIBS via feature_rust_lib and
falling back to -lz when zlib-rs is unavailable or when cross-compiling
bootstrap bpftool.

> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index b0f7168e79432..a193cf89a0346 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
[ ... ]
> @@ -38,7 +41,9 @@ $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DI
>  
>  $(LIBBPF): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_OUTPUT)
>  	$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_OUTPUT) \
> -		DESTDIR=$(LIBBPF_DESTDIR:/=) prefix= $(LIBBPF) install_headers
> +		DESTDIR=$(LIBBPF_DESTDIR:/=) prefix= \
> +		$(if $(ZLIB_CFLAGS),EXTRA_CFLAGS="$(or $(EXTRA_CFLAGS),-g -O2) $(ZLIB_CFLAGS)") \
> +		$(LIBBPF) install_headers
[ ... ]
> @@ -153,8 +178,27 @@ include $(FEATURES_DUMP)
>  endif
>  endif
>  
> -LIBS = $(LIBBPF) -lelf $(CRYPTO_LIBS) -lz
> -LIBS_BOOTSTRAP = $(LIBBPF_BOOTSTRAP) -lelf $(CRYPTO_LIBS) -lz
> +# Prefer zlib-rs over C zlib when detected. When cross-compiling, the host
> +# bootstrap bpftool still links against the host's -lz.
> +ifeq ($(feature-zlib-rs),1)
> +  $(call feature_rust_lib,zlib-rs)
> +  ZLIB_CFLAGS := $(FEATURE_CFLAGS-zlib-rs)
> +  ZLIB_LIBS := $(FEATURE_LIBS-zlib-rs)
> +  CFLAGS += $(ZLIB_CFLAGS)
> +  ifeq ($(CROSS_COMPILE),)
> +    HOST_CFLAGS += $(ZLIB_CFLAGS)
> +    LIBBPF_BOOTSTRAP_CFLAGS += $(ZLIB_CFLAGS)
> +    ZLIB_BOOTSTRAP_LIBS := $(ZLIB_LIBS)
> +  else
> +    ZLIB_BOOTSTRAP_LIBS := -lz
> +  endif
> +else
> +  ZLIB_LIBS := -lz
> +  ZLIB_BOOTSTRAP_LIBS := -lz
> +endif
> +
> +LIBS = $(LIBBPF) -lelf $(CRYPTO_LIBS) $(ZLIB_LIBS)
> +LIBS_BOOTSTRAP = $(LIBBPF_BOOTSTRAP) -lelf $(CRYPTO_LIBS) $(ZLIB_BOOTSTRAP_LIBS)

[Severity: Medium]
Can this cause a link failure with an undefined reference to gzopen64 when
bpftool is built using a pre-built libbpf.a on a host where zlib-rs is
detected?

In tools/lib/bpf/Makefile, libbpf is compiled with:

    override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

When tools/lib/bpf/libbpf.c is compiled without ZLIB_CFLAGS, bpf_object__read_kconfig_file()
includes the system zlib.h with those macros defined, which remaps gzopen()
to gzopen64() and leaves an undefined reference to gzopen64 in libbpf.a.
In contrast, libz-rs-sys only exports gzopen and not gzopen64, which is why
the $(LIBBPF) and $(LIBBPF_BOOTSTRAP) rules here pass $(ZLIB_CFLAGS) so that
libbpf uses the bundled zlib.h from libz-rs-sys.

However, several Makefiles build libbpf.a directly via tools/lib/bpf/Makefile
without ZLIB_CFLAGS and then pass that pre-built archive directory to
bpftool via LIBBPF_OUTPUT or LIBBPF_BOOTSTRAP_OUTPUT, such as
tools/testing/selftests/bpf/Makefile:

    $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile)    \
                        $(HOST_BPFOBJ) | $(HOST_BUILD_DIR)/bpftool
            $(Q)$(MAKE) $(submake_extras)  -C $(BPFTOOLDIR)                        \
                        ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)"         \
                        EXTRA_CFLAGS='-g $(OPT_FLAGS) $(SAN_CFLAGS) $(EXTRA_CFLAGS)' \
                        EXTRA_LDFLAGS='$(SAN_LDFLAGS) $(EXTRA_LDFLAGS)'            \
                        OUTPUT=$(HOST_BUILD_DIR)/bpftool/                          \
                        LIBBPF_OUTPUT=$(HOST_BUILD_DIR)/libbpf/

Similar patterns exist in tools/sched_ext/Makefile,
tools/testing/selftests/sched_ext/Makefile,
tools/testing/selftests/hid/Makefile, and drivers/hid/bpf/progs/Makefile.

Because $(LIBBPF) or $(LIBBPF_BOOTSTRAP) already exists and is up to date when
bpftool's Makefile runs, the $(LIBBPF) recipe with $(ZLIB_CFLAGS) is skipped,
while LIBS and LIBS_BOOTSTRAP replace -lz with $(ZLIB_LIBS) (libz_rs.a).
Wouldn't linking bpftool then fail with an unresolved gzopen64 symbol from the
pre-built libbpf.a?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029162958.3224280-1-irogers@google.com?part=3