Skip to content

Align using kernel version 6.18 LTS as the supported syscall surface - #303

Merged
jserv merged 5 commits into
sysprog21:mainfrom
henrybear327:kernel/6.18-lts
Aug 17, 2026
Merged

Align using kernel version 6.18 LTS as the supported syscall surface#303
jserv merged 5 commits into
sysprog21:mainfrom
henrybear327:kernel/6.18-lts

Conversation

@henrybear327

@henrybear327 henrybear327 commented Aug 16, 2026

Copy link
Copy Markdown
Collaborator

Currently, we are using kernel version 6.17 for the kernel syscall interface, and 6.12 for our qemu conformance test (alpine 3.21 is on Linux kernel version 6.12). This PR also cleans up the stale Lima-related comments.

There isn't any new syscall introduced between 6.17 and 6.18.

As 6.18 is a LTS kernel, it would be beneficial for us to support a kernel version that will last for years.


Summary by cubic

Aligns the reported and reference kernel with Linux 6.18 LTS. Guests now see 6.18 from uname and /proc/version, and the qemu oracle boots an Alpine 6.18 kernel; previously uname/proc reported 6.17 and the oracle ran 6.12. Syscall coverage is unchanged.

  • One source of truth: define GUEST_KERNEL_RELEASE="6.18.0" and GUEST_KERNEL_VERSION in src/syscall/sys.h; uname(2) and /proc/version read these. tests/test-proc.c enforces banner/uname agreement; tests/test-comprehensive.c asserts release >= 6.18 when nodename is elfuse.
  • Syscall surface unchanged: src/syscall/dispatch.tbl remains the implemented set; unimplemented 6.18 syscalls still return -ENOSYS.
  • Oracle lane: tests/fetch-fixtures.sh fetches linux-virt from Alpine 3.23 via KERNEL_ALPINE_VERSION (default 3.23) so the kernel and lib/modules match; userland pins stay on Alpine 3.21.
  • Docs: README and usage note the 6.18 floor; docs/internals.md documents the identity surfaces and limits.
  • Cleanups: remove Lima VM references; restate captured values as provenance.

Written for commit f54c034. Summary will update on new commits.

Review in cubic

uname(2) and /proc/version each spelled the reported kernel as a
private string literal, in syscall/sys.c and runtime/procemu.c, free
to drift apart. Both now read GUEST_KERNEL_RELEASE and
GUEST_KERNEL_VERSION from syscall/sys.h, which procemu.c already
includes. The reported values are unchanged.

Verified: the new tests/test-proc.c case pins the uname release into
the /proc/version banner, and fails when the two are forced apart.
The old release claimed a lima aarch64 VM kernel, but no lima
configuration or provisioning exists in this repo, and the only
kernel the tree boots is the qemu oracle's Alpine linux-virt. The
release now names the 6.18 LTS baseline, maintained through December
2027, and tracks no image.

Against dispatch.tbl, 6.18 is the smaller gap: 6.17 added
file_getattr and file_setattr, both above SC_MAX_SYSCALL_NUM and
ENOSYS here, while 6.18 added no syscalls. glibc's
dl_discover_osversion rejects only a release below its build-time
floor, so raising the number is the safe direction.

The /proc/version banner loses the buildd@bos03-arm64-051 builder
and the Ubuntu toolchain spellings: that host never built this, and
no Ubuntu release ships a 6.18 kernel. The builder and compiler
fields are now fixed elfuse strings in the proc_version_show format.

Coverage: tests/test-comprehensive.c asserts release >= 6.18 where
nodename is elfuse, so the same binary passes under the qemu oracle;
the check was seen failing with the floor raised past the release.
@henrybear327
henrybear327 requested a review from jserv August 16, 2026 21:02
@henrybear327 henrybear327 self-assigned this Aug 16, 2026
@henrybear327 henrybear327 changed the title Use kernel version 6.18 LTS as the supported syscall surface Align using kernel version 6.18 LTS as the supported syscall surface Aug 16, 2026
cubic-dev-ai[bot]

This comment was marked as resolved.

No doc named the kernel elfuse claims, the surfaces carrying the
claim, or its limits. docs/internals.md gains a Reported Kernel
Identity section: the two surfaces and their one definition, the
6.18 LTS rationale, the frozen LINUX_2.6.39 vDSO tag, the calls a
real 6.18 provides that elfuse answers with -ENOSYS, and the three
things that read the release automatically.

dispatch.tbl is the implemented set with two exceptions, so the
section names them: pidfd_getfd and userfaultfd are registered
there but their handlers return -ENOSYS. The readers are named per
lane, since test-proc and test-comprehensive both run under elfuse
and under the qemu oracle, and bench-hot-guard-glibc reads the
release through glibc's uname fallback without asserting on it.

README.md and docs/usage.md each carry one line, since a guest user
observes the version directly.
The oracle ran Alpine 3.21's linux-virt 6.12 while elfuse reports
6.18, so the differential lanes compared against a kernel two LTS
lines behind the claim. linux-virt now resolves from the Alpine 3.23
main repo, which ships 6.18; the kernel and its lib/modules tree
come from that one apk, so the 9p and virtio-net modules the boot
init loads match the kernel. The 37 userland pins stay on 3.21.

Verified: qemu_exec uname -r prints 6.18.44-0-virt, the 9p mount
holds, and both matrix lanes stay at their baselines.
Three comments assert a live correspondence with a lima VM that
exists nowhere in the repo: the sysinfo RAM cap says "Match Lima VZ
4GiB VM", rosetta.h says the probe values "match what the Lima-on-VZ
Linux VM observes", and proc.c restates its own provenance sentence
as "matching a real VZ (Lima) VM". The values are captured data; the
comments now say so and stop implying a sync obligation.
tests/test-poll.c stops naming lima as a lane the matrix does not
have; the setpgid variance is session-leader status, which follows
the launcher.
@jserv
jserv merged commit 4ad1bcf into sysprog21:main Aug 17, 2026
14 checks passed
@henrybear327
henrybear327 deleted the kernel/6.18-lts branch August 17, 2026 04:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants