Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 1

- [Medium] Incomplete fix: the capability probe still uses a different
  compiler than the one lib.mk installs to build `iou-zcrx`, in two…
- [Low] Missing `Fixes:` tag.

--

selftests: drv-net: Use cross-compilation environment for the io_uring check

This patch sets CC to $(CROSS_COMPILE)gcc at the top of
tools/testing/selftests/drivers/net/hw/Makefile so that the liburing
zero-copy capability probe (HAS_IOURING_ZCRX) is compiled with the
cross compiler instead of make's built-in default. The override is
guarded by ifeq ($(LLVM)$(CC),cc).

[Severity: Low]

Should this carry a Fixes: tag?  git blame on the baseline attributes the
whole probe block, including the ifeq ($(HAS_IOURING_ZCRX),y) gating, to
f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C
code").  Since no CC is set before the probe in this Makefile, in
tools/testing/selftests/Makefile, or in lib.mk, that commit is where the
probe started evaluating with the built-in CC=cc in cross builds:

  Fixes: f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C code")

On the changelog wording:

> The CC value used for the io_uring library check defaults to the host
> compiler, which will fail in cross-compiling environments.

Does the check actually fail?  The compile of the probe program succeeds or
fails against the host's liburing, so the result simply describes the host
rather than the target.  The failure comes later, when iou-zcrx is
cross-built and linked with -luring, or the test is silently dropped.
Would it be more accurate to describe it that way?

> diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
> index 6105be8e590f..f9458dc6c150 100644
> --- a/tools/testing/selftests/drivers/net/hw/Makefile
> +++ b/tools/testing/selftests/drivers/net/hw/Makefile
> @@ -1,5 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0+ OR MIT
>  
> +# Set CC for the io_uring check
> +ifeq ($(LLVM)$(CC),cc)
> +CC := $(CROSS_COMPILE)gcc
> +endif
> +

[Severity: Medium]

Can the probe and the actual build of iou-zcrx still end up on different
compilers after this change?  The guard only matches when LLVM is empty and
CC still holds the built-in value cc.

Two cases seem to slip through:

  make LLVM=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- ...

  $(LLVM)$(CC) expands to "1cc", the ifeq is false, so HAS_IOURING_ZCRX is
  probed with the host cc while lib.mk later sets:

    CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as

CC arriving from the environment with any value other than cc.  The
top-level kernel Makefile has:

    export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG

so kbuild-driven builds such as make kselftest always have CC in the
environment (plain clang with no --target under LLVM=1).  The ifeq is
false, the probe uses that compiler, but lib.mk's plain := assignment
overrides an environment CC for the real build:

    CC := $(CROSS_COMPILE)gcc

In both cases, a host liburing that has io_uring_register_ifq sets
HAS_IOURING_ZCRX=y, which adds iou-zcrx to COND_GEN_FILES and enables:

    $(OUTPUT)/iou-zcrx: LDLIBS += -luring

Does the subsequent cross compile then abort on liburing.h or -luring
instead of taking the graceful path?

    $(warning excluding iouring tests, liburing not installed or too old)

The inverse case, where the target sysroot has liburing but the host does
not, would silently drop a supported test.

Since the probe is expanded well before include ../../../lib.mk, would it
be possible to mirror lib.mk's own CC derivation here, or to move the probe
after lib.mk is included, so the gate always matches the compiler that
builds iou-zcrx?

>  # Check if io_uring supports zero-copy receive
>  HAS_IOURING_ZCRX := $(shell \
>  	echo -e '#include <liburing.h>\n' \

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903155524.2241065-1-maxime.chevallier%40bootlin.com