Skip to content

validation: adapt the hugetlb and rlimit tests to the host - #823

Open
dangowrt wants to merge 3 commits into
opencontainers:masterfrom
dangowrt:host-feature-gating
Open

dangowrt wants to merge 3 commits into
opencontainers:masterfrom
dangowrt:host-feature-gating

Conversation

@dangowrt

Copy link
Copy Markdown
Contributor

Some validation tests check things the host kernel cannot provide, so they fail against every runtime on such hosts. This makes them adapt to the host instead:

  • validation: skip the hugetlb tests without hugetlb support: linux_cgroups_hugetlb and linux_cgroups_relative_hugetlb now skip unless /proc/cgroups lists the hugetlb controller as enabled and /sys/kernel/mm/hugepages offers at least one page size. Without either, no runtime can apply linux.resources.hugepageLimits; the tests used to fail reading /sys/kernel/mm/hugepages. /proc/cgroups is created for both cgroup versions, so the check needs neither a cgroup v1 mount nor a v2 reader.
  • validation/linux_cgroups_hugetlb: report failures to start a container: when the runtime refused the container, testHugetlbCgroups() returned early, its deferred AutoPlan() printed 1..0 and main() exited through util.Fatal(), so the failure never showed up as a failed test and the invalid page size check did not run. Both checks now share one TAP stream and a failure to run the container is a failed test.
  • validation/process_rlimits: skip limits the host cannot hold: a 32-bit kernel stores rlimits in an unsigned long and turns any value of 4 GiB or more into RLIM_INFINITY, so the hard limits for RLIMIT_CORE, RLIMIT_DATA, RLIMIT_FSIZE and RLIMIT_STACK could never match there. The test now probes the host by setting a 4 GiB soft RLIMIT_FSIZE on itself and reading it back, and leaves out the limits of 4 GiB and more when the kernel cannot hold them. A 32-bit userland on a 64-bit kernel still tests all of them. The limits are left out rather than scaled down, because on a 32-bit kernel RLIMIT_STACK also sets the gap below the stack, and a finite multi-GiB value would leave the container little address space.

Tested with ujail on OpenWrt in QEMU: on x86_64 and i386 kernels without the hugetlb controller both hugetlb tests skip; on an x86_64 kernel with it, both run and pass (2MB limit set, the invalid 3MB page size refused); on i386 process_rlimits passes with the large limits left out, and on a 64-bit kernel it still sets all of them. go test ./validation/util/ covers the /proc/cgroups parser, and that the rlimit probe restores the original limit.

A kernel built without huge pages or without the hugetlb cgroup
controller cannot apply hugepage limits, so no runtime can pass the
hugetlb tests there; they failed on reading /sys/kernel/mm/hugepages.
Skip both tests unless /proc/cgroups lists the hugetlb controller as
enabled and the kernel offers at least one huge page size.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
When the runtime fails to create the container with a hugepage limit,
testHugetlbCgroups() returns the error, its deferred AutoPlan() prints
an empty plan and main() exits through util.Fatal(), so the failure
never shows up as a failed test. The second check then does not run at
all, and its own TAP header follows the first one in the same output.
Report both checks on one TAP stream and record a failure to run the
container as a failed test.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
@dangowrt
dangowrt marked this pull request as ready for review October 21, 2026 14:32
@dangowrt
dangowrt requested a review from a team as a code owner October 21, 2026 14:32
A 32-bit kernel stores resource limits in an unsigned long and turns
any value of 4 GiB or more into RLIM_INFINITY, so the hard limits for
RLIMIT_CORE, RLIMIT_DATA, RLIMIT_FSIZE and RLIMIT_STACK can never match
there. Probe the host by setting a 4 GiB soft RLIMIT_FSIZE on the test
itself, raising the hard limit as far as that needs, and reading it
back; leave out the limits of 4 GiB and more when this fails. A 32-bit
userland on a 64-bit kernel still tests all of them, and a runner
without CAP_SYS_RESOURCE under a lower hard limit leaves them out, as
a runtime it starts could not set them either.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
dangowrt added a commit to dangowrt/packages that referenced this pull request Oct 21, 2026
The hugetlb tests fail on kernels without huge pages or the hugetlb
cgroup controller, and the rlimit test sets limits of 4 GiB and more
that a 32-bit kernel turns into RLIM_INFINITY, so they fail against
every runtime on most OpenWrt targets. Carry the pending upstream
fixes that skip the hugetlb tests on such kernels, report a refused
hugetlb container as a failed test and leave out the rlimits the host
cannot hold.

Link: opencontainers/runtime-tools#823
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
@dangowrt
dangowrt force-pushed the host-feature-gating branch from b7297ff to ffe110f Compare October 21, 2026 22:54
dangowrt added a commit to openwrt/packages that referenced this pull request Oct 22, 2026
The hugetlb tests fail on kernels without huge pages or the hugetlb
cgroup controller, and the rlimit test sets limits of 4 GiB and more
that a 32-bit kernel turns into RLIM_INFINITY, so they fail against
every runtime on most OpenWrt targets. Carry the pending upstream
fixes that skip the hugetlb tests on such kernels, report a refused
hugetlb container as a failed test and leave out the rlimits the host
cannot hold.

Link: opencontainers/runtime-tools#823
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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.

1 participant