mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: maxime.chevallier@bootlin.com
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, donald.hunter@gmail.com,
	horms@kernel.org, shuah@kernel.org, matttbe@kernel.org,
	sdf@fomichev.me, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check
Date: Sun, 06 Sep 2026 15:00:20 +0000	[thread overview]
Message-ID: <178870682049.219967.8686151218558794028@kernel.org> (raw)
In-Reply-To: <20260903155524.2241065-3-maxime.chevallier@bootlin.com>

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

  parent reply	other threads:[~2026-09-06 15:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 15:55 [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests Maxime Chevallier (Netdev Foundation)
2026-09-03 15:55 ` [PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools Maxime Chevallier (Netdev Foundation)
2026-09-03 16:22   ` Matthieu Baerts
2026-09-06 15:00   ` netdev-bot+sashiko
2026-09-07  8:22     ` Maxime Chevallier
2026-09-07  9:36       ` Matthieu Baerts
2026-09-03 15:55 ` [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check Maxime Chevallier (Netdev Foundation)
2026-09-03 16:22   ` Matthieu Baerts
2026-09-06 15:00   ` netdev-bot+sashiko [this message]
2026-09-07 13:51     ` Maxime Chevallier
2026-09-07 13:58       ` Matthieu Baerts
2026-09-03 16:51 ` [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests Andrew Lunn
2026-09-03 17:25   ` Matthieu Baerts
2026-09-03 21:44   ` Maxime Chevallier
2026-09-03 21:59     ` Andrew Lunn
2026-09-04  6:11       ` Maxime Chevallier
2026-09-03 23:40     ` Jakub Kicinski
2026-09-03 17:11 ` Andrew Lunn
2026-09-03 17:25   ` Matthieu Baerts
2026-09-03 20:55     ` Andrew Lunn
2026-09-04  9:43       ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178870682049.219967.8686151218558794028@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=matttbe@kernel.org \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®