[LTP] [PATCH v1] overcommit_memory: Fix integer overflow and 32-bit limits

[Arnd Bergmann]

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