From: Petr Vorel <pvorel@suse.cz>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: arnd@arndb.de, lkft-triage@lists.linaro.org, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] overcommit_memory: Fix integer overflow and 32-bit limits
Date: Wed, 15 Oct 2025 18:02:24 +0200 [thread overview]
Message-ID: <20251015160224.GC220875@pevik> (raw)
In-Reply-To: <aO-2-tN418z9wDKm@stanley.mountain>
> On Wed, Oct 15, 2025 at 04:42:47PM +0200, Petr Vorel 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
> > You still mention GB ...
> Yep. It is GB.
> > > 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>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Reviewed-by: Petr Vorel <pvorel@suse.cz>
> > > ---
> > > .../kernel/mem/tunable/overcommit_memory.c | 33 +++++++++++++++----
> > > 1 file changed, 27 insertions(+), 6 deletions(-)
> > > diff --git a/testcases/kernel/mem/tunable/overcommit_memory.c b/testcases/kernel/mem/tunable/overcommit_memory.c
> > > index 9b2cb479d..7ff5a98d0 100644
> > > --- a/testcases/kernel/mem/tunable/overcommit_memory.c
> > > +++ b/testcases/kernel/mem/tunable/overcommit_memory.c
> > > @@ -131,24 +131,45 @@ static void overcommit_memory_test(void)
> > > TST_SYS_CONF_LONG_SET(OVERCOMMIT_MEMORY, 2, 1);
> > > update_mem_commit();
> > > - alloc_and_check(commit_left * 2, EXPECT_FAIL);
> > > - alloc_and_check(commit_limit + total_batch_size, EXPECT_FAIL);
> > > + /* Skip tests that would overflow or exceed 32-bit address space */
> > > + if (tst_kernel_bits() == 64 || (unsigned long)commit_left <= TST_GB / TST_KB) {
> > ... but TST_GB / TST_KB is actually MB (you could use TST_MB).
> The sizes in this test are measured in KB, so it's 1GB but measured in
> terms of KB not bytes. Using TST_MB would work mathematically but it's
> misleading.
Ah, I'm sorry to overlook an obvious point.
Implementation details: thinking about the code twice, shouldn't be the check
for overflow in alloc_and_check() instead of outside (to keep the condition on
single place)?
Also, if kept outside the 1st and 2nd if could be joined:
/* Skip tests that would overflow or exceed 32-bit address space */
if (tst_kernel_bits() == 64 || (unsigned long)commit_left <= TST_GB / TST_KB) {
alloc_and_check(commit_left * 2, EXPECT_FAIL);
alloc_and_check(commit_limit + total_batch_size, EXPECT_FAIL);
update_mem_commit();
alloc_and_check(commit_left / 2, EXPECT_PASS);
} else {
tst_res(TCONF, "Skipping large allocation tests due to address space limits");
}
instead of your proposal:
update_mem_commit();
/* Skip tests that would overflow or exceed 32-bit address space */
if (tst_kernel_bits() == 64 || (unsigned long)commit_left <= TST_GB / TST_KB) {
alloc_and_check(commit_left * 2, EXPECT_FAIL);
alloc_and_check(commit_limit + total_batch_size, EXPECT_FAIL);
} else {
tst_res(TCONF, "Skipping large allocation tests due to address space limits");
}
update_mem_commit();
if (tst_kernel_bits() == 64 || (unsigned long)commit_left <= TST_GB / TST_KB) {
alloc_and_check(commit_left / 2, EXPECT_PASS);
} else {
tst_res(TCONF, "Skipping commit_left/2 allocation test due to address space limits");
}
because update_mem_commit() IMHO just evaluates /proc/meminfo values, but
when alloc_and_check() is skipped nothing has changed.
Kind regards,
Petr
> regards,
> dan carpenter
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-10-15 16:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 10:15 [LTP] [PATCH v2] overcommit_memory: Fix integer overflow and 32-bit limits Ben Copeland
2025-10-15 14:42 ` Petr Vorel
2025-10-15 15:00 ` Dan Carpenter
2025-10-15 16:02 ` Petr Vorel [this message]
2025-10-16 12:36 ` Ben Copeland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251015160224.GC220875@pevik \
--to=pvorel@suse.cz \
--cc=arnd@arndb.de \
--cc=dan.carpenter@linaro.org \
--cc=lkft-triage@lists.linaro.org \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.