On Fri, Oct 10, 2025, at 11:04, Ben Copeland wrote:
The overcommit test uses sum_total, the sum (memory and swap) to test the overcommit settings.
This fixes two problems on 32-bit systems. The first is seen with a integer overflow can occur when calculating sum_total * 2, if the sum_total is larger than 2GB. The second is limited virtual address space (2-3GB) means the test can fail from address space exhaustion before overcommit has been tested.
Now the test runs correctly on low-memory 32-bit systems while avoiding both the overflow bug and virtual address space issues.
Signed-off-by: Ben Copeland ben.copeland@linaro.org
The logic makes sense to me.
Acked-by: Arnd Bergmann arnd@arndb.de
update_mem(); alloc_and_check(free_total / 2, EXPECT_PASS);
- alloc_and_check(sum_total * 2, EXPECT_FAIL);
- /* Skip if sum_total * 2 would exceed address space.
* On 32-bit, skip when sum_total > ULONG_MAX/4 (~1GB).
* Most 32-bit systems with <=1GB RAM can map 2x that in 3GB vaddr space.
* Systems with 2GB+ RAM likely cannot fit allocations in vaddr space. */
- if (tst_kernel_bits() == 64 || (unsigned long)sum_total <= ONE_GB) {
alloc_and_check(sum_total * 2, EXPECT_FAIL);
- } else {
tst_res(TCONF, "Skipping large allocation test due to address space limits");
- }
It would be nice if it was possible to express this in terms of the kernel's TASK_SIZE constant and not have to check for 64-bit kernels.
Unfortunately I have not been able find TASK_SIZE from userspace directly other than maybe probing MAP_FIXED mmap() calls which would be overly complicated. Your approach is probably as good as it gets.
Arnd