All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
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


  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.