On 07/09/2026 15:51, Maxime Chevallier wrote: > Hi, > > On 9/6/26 17:00, [email protected] wrote: >> 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") > > Yeah but OTHO this never worked, and apparently was never tested before. > >> >> 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. > > I'll reword yeah... > > [...] > >> >> 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? > > Well this is what I wanted to avoid :( > > Let me reword the commit log for V2, Matthieu if that's OK I'll also keep your > R-b, as I'll leave the code as-is unless someone has any objection ?
Fine by me to document this "limitation" but keep it as is: I think the proposed "workaround" is enough for this case. Cheers, Matt
