From: Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: [Devel] [PATCH vz10 v3 0/2] selftests: build test modules for the packaged kernel
Date: Thu, 13 Aug 2026 19:58:04 +0200 [thread overview]
Message-ID: <20260813175806.236084-1-khorenko@virtuozzo.com> (raw)
In-Reply-To: <20260812094921.162724-1-eva.kurchatova@virtuozzo.com>
The in-tree test modules of the selftests are built against the wrong
kernel, or not built at all, when the selftests are built as part of a
kernel package.
The livepatch, cgroup and mm/page_frag test module Makefiles default
KDIR to /lib/modules/$(uname -r)/build, which is the build tree of the
kernel running on the build host, not of the kernel being packaged. The
result is visible in the kernel-selftests rpm we ship today: of all
in-tree test modules only the bpf ones are there, and bpf/test_kmods is
exactly the one which already defaults KDIR to the kernel tree it
belongs to. Patch 2 makes the others do the same, and lets KDIR follow
an O= or KBUILD_OUTPUT build directory as well.
Patch 1 drops the KDIR existence checks around the recipes instead of
fixing them, which is the main change since v2. My reasoning:
- A silent skip is the worst possible outcome for a packaged testsuite.
The modules are simply absent from the rpm, the build log says nothing
about it, and the failure surfaces much later on a test node as a test
which cannot find its module, far away from the cause. A build failure
is strictly better: it happens where the kernel tree is, and it says
what is missing.
- The check did not even do what it promised. $(wildcard) reports the
name of a symlink without resolving it, so for the default KDIR of
/lib/modules/$(uname -r)/build, which commonly is a dangling symlink
left behind by an uninstalled kernel-devel package, the check passed
and the build failed in make -C anyway.
- Nothing is lost by dropping it. The selftests framework already
implements the "do not fail everything because of one target" policy,
and it does so honestly, leaving the error of the failing target in
the build log:
all:
@ret=1; \
for TARGET in $(TARGETS); do \
$(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET \
O=$(abs_objtree) \
$(if $(FORCE_TARGETS),|| exit); \
ret=$$((ret * $$?)); \
done; exit $$ret;
The exit status is the product of the per-target statuses seeded with
1, so one failing target does not abort the run and is masked by any
later successful one, while FORCE_TARGETS=1 makes the loop strict.
Choosing between the two belongs to whoever runs the build, and a
Makefile which reports success no matter what takes that choice away:
kernel packaging passes FORCE_TARGETS=1 exactly because it wants to
know whether every test module has been built. Dropping the checks
also makes the tree consistent, bpf/test_kmods and mm/page_frag never
had one and simply fail.
One warning based skip is left alone on purpose. mm/Makefile decides
whether to build page_frag_test.ko by looking for
include/linux/page_frag_cache.h, and an older kernel legitimately does
not have that API; that check prints a warning and the test skips at
runtime with the kselftest skip code. Its neighbouring "missing
Module.symvers" branch is not feature detection though, and is a
candidate for the same treatment later.
Changes since v2:
- Split into two patches, so that dropping the KDIR checks is a separate
change with its own reasoning.
- Drop the checks instead of fixing them to test $(KDIR)/Makefile.
- Trim the commit message and the in-code comments, which repeated the
same rationale in four Makefiles.
Eva Kurchatova (1):
selftests: build test modules against the kernel tree
Konstantin Khorenko (1):
selftests: do not hide a missing kernel build tree
.../testing/selftests/bpf/test_kmods/Makefile | 20 +++++++++++++-
.../selftests/cgroup/test_modules/Makefile | 24 ++++++++++++-----
.../selftests/livepatch/test_modules/Makefile | 24 ++++++++++++-----
tools/testing/selftests/mm/Makefile | 27 ++++++++++++++++++-
tools/testing/selftests/mm/page_frag/Makefile | 18 +++++++++++++
5 files changed, 99 insertions(+), 14 deletions(-)
--
2.43.0
next prev parent reply other threads:[~2026-08-13 17:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 9:49 [Devel] [PATCH vz10 v2] selftests: build test modules against the kernel tree Eva Kurchatova
2026-08-13 17:58 ` Konstantin Khorenko [this message]
2026-08-13 17:58 ` [Devel] [PATCH vz10 v3 1/2] selftests: do not hide a missing kernel build tree Konstantin Khorenko
2026-08-14 11:11 ` [Devel] [PATCH RHEL10 COMMIT] " Konstantin Khorenko
2026-08-13 17:58 ` [Devel] [PATCH vz10 v3 2/2] selftests: build test modules against the kernel tree Konstantin Khorenko
2026-08-14 11:11 ` [Devel] [PATCH RHEL10 COMMIT] " Konstantin Khorenko
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=20260813175806.236084-1-khorenko@virtuozzo.com \
--to=khorenko@virtuozzo.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 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.