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 --- .../kernel/mem/tunable/overcommit_memory.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/testcases/kernel/mem/tunable/overcommit_memory.c b/testcases/kernel/mem/tunable/overcommit_memory.c index 9b2cb479d..f9f60ebc3 100644 --- a/testcases/kernel/mem/tunable/overcommit_memory.c +++ b/testcases/kernel/mem/tunable/overcommit_memory.c @@ -68,6 +68,7 @@ #define DEFAULT_OVER_RATIO 50L #define EXPECT_PASS 0 #define EXPECT_FAIL 1 +#define ONE_GB (1024 * 1024 * TST_KB)
#define OVERCOMMIT_MEMORY "/proc/sys/vm/overcommit_memory" #define OVERCOMMIT_RATIO "/proc/sys/vm/overcommit_ratio" @@ -141,14 +142,26 @@ static void overcommit_memory_test(void)
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"); + }
/* start to test overcommit_memory=1 */ TST_SYS_CONF_LONG_SET(OVERCOMMIT_MEMORY, 1, 1);
alloc_and_check(sum_total / 2, EXPECT_PASS); - alloc_and_check(sum_total, EXPECT_PASS); - alloc_and_check(sum_total * 2, EXPECT_PASS); + if (tst_kernel_bits() == 64 || (unsigned long)sum_total <= ONE_GB) { + alloc_and_check(sum_total, EXPECT_PASS); + alloc_and_check(sum_total * 2, EXPECT_PASS); + } else { + tst_res(TCONF, "Skipping large allocation tests due to address space limits"); + }
}
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
Hi all,
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.
Thanks for looking into the issue.
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) {
Why not use TST_GB instead of creating new constant ONE_GB?
#define ONE_GB (1024 * 1024 * TST_KB)
Maybe even use static variable holding the condition and set it in setup()?
Otherwise LGTM.
Reviewed-by: Petr Vorel pvorel@suse.cz
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.
Thanks for your time!
BTW in our case (openSUSE Tumbleweed 32 bit) it fails on commit_left, which is slightly smaller: commit_left: 2221904 sum_total: 2884328
tst_kernel.c:90: TINFO: uname.machine=i686 kernel is 32bit tst_test.c:2021: TINFO: LTP version: 20251010.79b7f212 tst_test.c:2024: TINFO: Tested kernel: 6.17.1-1-default #1 SMP PREEMPT_DYNAMIC Tue Oct 7 04:26:30 UTC 2025 (1bf5c2e) i686 tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz' tst_kconfig.c:676: TINFO: CONFIG_FAULT_INJECTION kernel option detected which might slow the execution tst_test.c:1842: TINFO: Overall timeout per run is 0h 02m 00s overcommit_memory.c:103: TINFO: MemTotal is 2050380 kB overcommit_memory.c:105: TINFO: SwapTotal is 2098152 kB overcommit_memory.c:109: TINFO: CommitLimit is 3121292 kB overcommit_memory.c:122: TINFO: Setting /proc/sys/vm/overcommit_ratio to 50 overcommit_memory.c:125: TINFO: TotalBatchSize is 8008 kB overcommit_memory.c:131: TINFO: Setting /proc/sys/vm/overcommit_memory to 2 overcommit_memory.c:161: TINFO: malloc 5738112 kB successfully overcommit_memory.c:188: TFAIL: alloc passed, expected to fail overcommit_memory.c:165: TINFO: malloc 3129300 kB failed overcommit_memory.c:186: TPASS: alloc failed as expected overcommit_memory.c:161: TINFO: malloc 1434528 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:140: TINFO: Setting /proc/sys/vm/overcommit_memory to 0 overcommit_memory.c:161: TINFO: malloc 1804260 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:165: TINFO: malloc 8297064 kB failed overcommit_memory.c:186: TPASS: alloc failed as expected overcommit_memory.c:147: TINFO: Setting /proc/sys/vm/overcommit_memory to 1 overcommit_memory.c:161: TINFO: malloc 2074266 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:165: TINFO: malloc 4148532 kB failed overcommit_memory.c:182: TFAIL: alloc failed, expected to pass overcommit_memory.c:165: TINFO: malloc 8297064 kB failed overcommit_memory.c:182: TFAIL: alloc failed, expected to pass
Kind regards, Petr
Arnd
Hello Petr,
On Mon, 13 Oct 2025 at 16:00, Petr Vorel pvorel@suse.cz wrote:
Hi all,
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.
Thanks for looking into the issue.
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) {
Why not use TST_GB instead of creating new constant ONE_GB?
This makes sense, I will do that.
#define ONE_GB (1024 * 1024 * TST_KB)
Maybe even use static variable holding the condition and set it in setup()?
Otherwise LGTM.
Reviewed-by: Petr Vorel pvorel@suse.cz
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.
Thanks for your time!
BTW in our case (openSUSE Tumbleweed 32 bit) it fails on commit_left, which is slightly smaller: commit_left: 2221904 sum_total: 2884328
Ah, good spot. This is failing further up the code; this fix was for overcommit_memory=1. It's hitting the same integer overflow issue. I will apply the same fix to overcommit_memory=2 and spin up a v2 patch.
Thanks for the feedback!
Regards,
Ben
tst_kernel.c:90: TINFO: uname.machine=i686 kernel is 32bit tst_test.c:2021: TINFO: LTP version: 20251010.79b7f212 tst_test.c:2024: TINFO: Tested kernel: 6.17.1-1-default #1 SMP PREEMPT_DYNAMIC Tue Oct 7 04:26:30 UTC 2025 (1bf5c2e) i686 tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz' tst_kconfig.c:676: TINFO: CONFIG_FAULT_INJECTION kernel option detected which might slow the execution tst_test.c:1842: TINFO: Overall timeout per run is 0h 02m 00s overcommit_memory.c:103: TINFO: MemTotal is 2050380 kB overcommit_memory.c:105: TINFO: SwapTotal is 2098152 kB overcommit_memory.c:109: TINFO: CommitLimit is 3121292 kB overcommit_memory.c:122: TINFO: Setting /proc/sys/vm/overcommit_ratio to 50 overcommit_memory.c:125: TINFO: TotalBatchSize is 8008 kB overcommit_memory.c:131: TINFO: Setting /proc/sys/vm/overcommit_memory to 2 overcommit_memory.c:161: TINFO: malloc 5738112 kB successfully overcommit_memory.c:188: TFAIL: alloc passed, expected to fail overcommit_memory.c:165: TINFO: malloc 3129300 kB failed overcommit_memory.c:186: TPASS: alloc failed as expected overcommit_memory.c:161: TINFO: malloc 1434528 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:140: TINFO: Setting /proc/sys/vm/overcommit_memory to 0 overcommit_memory.c:161: TINFO: malloc 1804260 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:165: TINFO: malloc 8297064 kB failed overcommit_memory.c:186: TPASS: alloc failed as expected overcommit_memory.c:147: TINFO: Setting /proc/sys/vm/overcommit_memory to 1 overcommit_memory.c:161: TINFO: malloc 2074266 kB successfully overcommit_memory.c:180: TPASS: alloc passed as expected overcommit_memory.c:165: TINFO: malloc 4148532 kB failed overcommit_memory.c:182: TFAIL: alloc failed, expected to pass overcommit_memory.c:165: TINFO: malloc 8297064 kB failed overcommit_memory.c:182: TFAIL: alloc failed, expected to pass
Kind regards, Petr
Arnd
-
Arnd Bergmann -
Ben Copeland -
Petr Vorel