All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sasha Levin" <sashal@kernel.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nsc@kernel.org>,
	linux-kbuild@vger.kernel.org
Cc: "Shuah Khan" <shuah@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"James Clark" <james.clark@linaro.org>,
	linux-perf-users@vger.kernel.org,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH v2 5/7] tools: build kernel selftests in tools_build
Date: Sat, 17 Oct 2026 14:32:12 +0000	[thread overview]
Message-ID: <sashiko-outbox-175556@kernel.org> (raw)
In-Reply-To: <20261016143143.3613501-6-sashal@kernel.org>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] build: Fatal Make syntax error on empty target variables in static pattern rules
- [Medium] selftests: kexec Kconfig unnecessarily restricted to X86_64
- [Medium] kbuild: missing dependencies on scripts/ Makefiles for selftests rebuilds
--

commit f8d06182dd0adbe69406863fbe53894162f78089
Author: Sasha Levin <sashal@kernel.org>
Subject: tools: build kernel selftests in tools_build

This commit adds a "Kernel selftests" sub-menu to the tools build framework,
allowing selftests to be built without writing to the source tree. Each
selftest runs under its own make instance, enabling parallel builds using a
pre-installed C library and UAPI headers. Rebuild dependencies are handled by
tracking timestamps of shared files and headers since selftests do not
natively track header dependencies.

> diff --git a/tools/Kconfig b/tools/Kconfig
> --- a/tools/Kconfig
> +++ b/tools/Kconfig

[ ... ]

> +config TOOLS_BUILD_SELFTESTS_KEXEC
> +	bool "kexec"
> +	depends on X86_64

[Severity: Medium]
Does this unnecessarily restrict the kexec selftest to X86_64?

Looking at tools/testing/selftests/kexec/Makefile, it explicitly supports both
x86 (32-bit and 64-bit) and ppc64le:

    ifeq ($(ARCH_PROCESSED),$(filter $(ARCH_PROCESSED),x86 ppc64le))
    TEST_PROGS := test_kexec_load.sh test_kexec_file_load.sh
    TEST_FILES := kexec_common_lib.sh

Configuring the tools build on ppc64le or 32-bit x86 will not expose this
option, silently excluding the test from being built and installed on these
platforms.

[ ... ]

> diff --git a/tools/Makefile.kbuild b/tools/Makefile.kbuild
> --- a/tools/Makefile.kbuild
> +++ b/tools/Makefile.kbuild

[ ... ]

> +$(selftest-shared): FORCE
> +	$(Q)mkdir -p $(@D); \
> +	newest=$$(find $(CURDIR)/usr/include $(toolsdir)/include $(toolsdir)/arch $(toolsdir)/testing/selftests \
> +		-type f \( -name '*.h' -o -name '*.mk' -o -name Makefile \) -printf '%T@\n' | \
> +		sort -n | tail -n 1); \
> +	touch -d "@$${newest:-0}" $@

[Severity: Medium]
Will this miss rebuild dependencies on shared build scripts?

The find command omits the tools/scripts/ and scripts/ directories, and its
filters exclude files named Makefile.* or *.include.

Modifying core shared files like tools/scripts/Makefile.include,
tools/scripts/Makefile.arch, or scripts/subarch.include will not trigger a
rebuild of selftests that include them, which can lead to stale builds.

> +
> +# As with "make kselftest-all", a selftest that fails to build does not fail
> +# the build unless FORCE_TARGETS is set. kselftest_deps.sh lists the libraries
> +# it needs that the compiler cannot link with. It leaves files behind in
> +# TMPDIR, so it gets one of its own.
> +selftest-failed = (cd $(toolsdir)/testing/selftests && tmp=$$(mktemp -d) && \
> +	TMPDIR=$$tmp ./kselftest_deps.sh '$(call escsq,$(tools-cc))' $(1) | grep '^FAIL' >&2; \
> +	rm -rf "$$tmp"); $(if $(FORCE_TARGETS),false,:)
> +
> +selftest-targets := $(addprefix selftest-,$(selftests-y))
> +
> +__tools_build: $(selftest-targets)
> +
> +PHONY += $(selftest-targets)
> +$(selftest-targets): selftest-%: $(selftest-shared) FORCE
> +	$(call build,$(outdir)/selftests/$*,-C $(toolsdir)/testing/selftests/$* OUTPUT=$(outdir)/selftests/$* $(selftest-flags),$(selftest-shared) $(toolsdir)/testing/selftests/$* $(selftest-extra-$*),TOOLS_BUILD_SELFTESTS_$(shell echo $* | tr a-z/- A-Z__),$(call selftest-failed,$*))

[Severity: High]
Can this trigger a fatal Make syntax error if no selftests are selected?

If a user enables the tools build selftests option but disables all individual
selftests, $(selftests-y) and $(selftest-targets) will be empty.

Since this rule uses two colons, it is a static pattern rule. While GNU Make
ignores empty targets for single-colon rules, an empty target list in a
double-colon static pattern rule evaluates to : selftest-%: ... and
triggers a fatal missing target pattern. Stop. build error.

The same issue would apply to the $(tool-targets): tool-%: FORCE rule if
the tools build is enabled but no individual tools are selected.

Should these static pattern rules be guarded with an ifneq check
(e.g., ifneq ($(selftest-targets),)) to prevent breaking the build on
minimal configurations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016143143.3613501-1-sashal@kernel.org?part=5

  parent reply	other threads:[~2026-10-17 14:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 14:31 [RFC PATCH v2 0/7] kbuild: build the userspace tools in tools/ with the kernel Sasha Levin
2026-10-16 14:31 ` [RFC PATCH v2 1/7] kbuild: factor the userspace ABI flags out into KBUILD_USERABI Sasha Levin
2026-10-17 14:32   ` sashiko-bot
2026-10-16 14:31 ` [RFC PATCH v2 2/7] kbuild: add "make tools_build" to build userspace tools from tools/ Sasha Levin
2026-10-17 14:32   ` sashiko-bot
2026-10-16 14:31 ` [RFC PATCH v2 3/7] perf build: Add MINIMAL=1 to build without optional features Sasha Levin
2026-10-16 15:41   ` Ian Rogers
2026-10-17 14:32   ` sashiko-bot
2026-10-16 14:31 ` [RFC PATCH v2 4/7] tools: build perf in tools_build Sasha Levin
2026-10-17 14:32   ` sashiko-bot
2026-10-16 14:31 ` [RFC PATCH v2 5/7] tools: build kernel selftests " Sasha Levin
2026-10-16 16:17   ` Shuah Khan
2026-10-17 14:32   ` sashiko-bot [this message]
2026-10-16 14:31 ` [RFC PATCH v2 6/7] kbuild: build the tools selected in tools/Kconfig as part of "make all" Sasha Levin
2026-10-17 14:32   ` sashiko-bot
2026-10-16 14:31 ` [RFC PATCH v2 7/7] Documentation: describe building tools with the kernel Sasha Levin
2026-10-17 14:32   ` sashiko-bot

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=sashiko-outbox-175556@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sashal@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shuah@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.