Linux 7.4-rc1 makes missing self-tests harder to mistake for success

Linux 7.4 has entered its first release-candidate stage with a small but consequential improvement for people testing the kernel: a successful build can now be accompanied by a record of which self-test suites actually built. That distinction matters because a green result from the build command has never necessarily meant that every requested test was available to run.

The 7.4-rc1 tag marks the beginning of stabilization, rather than a finished kernel for ordinary upgrades. Among the changes integrated for this cycle, the kselftest documentation in that exact version describes a new machine-readable build report. Its purpose is to make gaps visible before they are mistaken for coverage.

A green command can hide missing tests

Kselftest is the kernel's collection of tests for exercising its interfaces and behavior. Building those tests is a separate operation from running them. A test cannot fail during execution if it was never built and therefore never reached the machine doing the testing.

The framework deliberately accommodates partial builds. Unless stricter behavior is requested, its top-level build can succeed when at least one target builds successfully. That can be useful across systems with different architectures and dependencies: a missing prerequisite for one suite should not always prevent every other suite from being used.

The trouble starts when an automated job interprets that successful return code as evidence that the entire planned test set exists. Consider a job intended to prepare two suites. One compiles; the other lacks a dependency. The surrounding job can look healthy while its effective coverage has shrunk. This is an example of the documented policy, not a claim about a particular failed kernel release.

An auditable list instead of one exit code

Setting KSFT_BUILD_REPORT supplies a file to which the build and installation steps append records. Each contains a phase, target name and exit status. The format is tab-separated, so a continuous-integration system can compare the results with the suites it expected, without attempting to interpret a long terminal transcript.

There are important reading rules. A target may appear more than once because installation can trigger another build, and some suites contain subdirectories with their own records. The documentation says a target is successful only when all its associated records have zero status. A missing record is not proof of success. The caller also controls creation or truncation of the report; appending a fresh run to an old file without distinguishing them would undermine the comparison.

This is useful precisely because it does not pretend to solve everything. The report records preparation of the tests. It does not certify that those tests subsequently ran, that their assertions cover every relevant behavior, or that a kernel is free of regressions.

Reporting and enforcement remain separate

The versioned self-test Makefile keeps the existing policy explicit. FORCE_TARGETS=1 asks the build to stop when a target fails. The optional report does not itself change that policy or the command's exit status.

Those controls serve different workflows. A tightly specified test machine may reasonably require every planned suite. A broader build farm may accept partial results while recording exactly which combinations remain untested. The useful change is that the second approach need not reduce its evidence to a single ambiguous success signal.

For readers following Linux coverage, this is also a reminder of what a release candidate is for. The kernel's development-process documentation describes the period after the merge window as stabilization, with regressions receiving particular attention. The new reporting makes one part of that work easier to audit. The valuable outcome is not a greener dashboard; it is knowing which parts of the kernel the green dashboard actually covers.