[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[Thadeu Lima de Souza Cascardo]

Though on recent kernels (starting with 5.2, commit
8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive
OVERCOMMIT_GUESS failures"), overcommit accounting allows for allocating up
to MemTotal memory, older kernels have a much more complicated overcommit
guess accounting.

That leads to mmap failing on small enough systems:

mmap1.c:205: TBROK: mmap((nil),2088370176,3,34,-1,0) failed: ENOMEM (12)

Allocating only half of the total memory would generally work on test
systems.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
---
 testcases/kernel/mem/mtest06/mmap1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/mem/mtest06/mmap1.c b/testcases/kernel/mem/mtest06/mmap1.c
index 56588e1ebaff..10c47c35cb02 100644
--- a/testcases/kernel/mem/mtest06/mmap1.c
+++ b/testcases/kernel/mem/mtest06/mmap1.c
@@ -186,7 +186,7 @@ static void setup(void)
 {
 	struct sigaction sigptr;
 	size_t distant_mmap_size;
-	long mem_total;
+	size_t mem_total;
 
 	page_sz = getpagesize();
 	mem_total = SAFE_READ_MEMINFO("MemTotal:");
@@ -195,7 +195,7 @@ static void setup(void)
 #ifdef TST_ABI32
 	distant_mmap_size = 256*1024*1024;
 #else
-	distant_mmap_size = (mem_total > 2 * GIGABYTE) ? 2 * GIGABYTE : mem_total;
+	distant_mmap_size = (mem_total > 4 * GIGABYTE) ? 2 * GIGABYTE : mem_total / 2;
 #endif
 	/*
 	 * Used as hint for mmap thread, so it doesn't interfere
-- 
2.30.2

[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[Jan Stancek]

On Wed, May 19, 2021 at 3:22 PM Thadeu Lima de Souza Cascardo
<cascardo@canonical.com> wrote:
>
> Though on recent kernels (starting with 5.2, commit
> 8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive
> OVERCOMMIT_GUESS failures"), overcommit accounting allows for allocating up
> to MemTotal memory, older kernels have a much more complicated overcommit
> guess accounting.
>
> That leads to mmap failing on small enough systems:
>
> mmap1.c:205: TBROK: mmap((nil),2088370176,3,34,-1,0) failed: ENOMEM (12)
>
> Allocating only half of the total memory would generally work on test
> systems.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

Thanks for patch.

Acked-by: Jan Stancek <jstancek@redhat.com>

[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[Cyril Hrubis]

Hi!
> > Though on recent kernels (starting with 5.2, commit
> > 8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive
> > OVERCOMMIT_GUESS failures"), overcommit accounting allows for allocating up
> > to MemTotal memory, older kernels have a much more complicated overcommit
> > guess accounting.
> >
> > That leads to mmap failing on small enough systems:
> >
> > mmap1.c:205: TBROK: mmap((nil),2088370176,3,34,-1,0) failed: ENOMEM (12)
> >
> > Allocating only half of the total memory would generally work on test
> > systems.
> >
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> 
> Thanks for patch.
> 
> Acked-by: Jan Stancek <jstancek@redhat.com>

Looks safe enough for the release, as far as I can tell the test
shouldn't care at all where we map the block of memory.

Jan looks like you originaly wrote the test, do you agree that this
should go in now?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[Cyril Hrubis]

Hi!
Pushed, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] mtest06/mmap1: Further limit distant mmap size

[Jan Stancek]

On Thu, May 20, 2021 at 1:43 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > > Though on recent kernels (starting with 5.2, commit
> > > 8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive
> > > OVERCOMMIT_GUESS failures"), overcommit accounting allows for allocating up
> > > to MemTotal memory, older kernels have a much more complicated overcommit
> > > guess accounting.
> > >
> > > That leads to mmap failing on small enough systems:
> > >
> > > mmap1.c:205: TBROK: mmap((nil),2088370176,3,34,-1,0) failed: ENOMEM (12)
> > >
> > > Allocating only half of the total memory would generally work on test
> > > systems.
> > >
> > > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> >
> > Thanks for patch.
> >
> > Acked-by: Jan Stancek <jstancek@redhat.com>
>
> Looks safe enough for the release, as far as I can tell the test
> shouldn't care at all where we map the block of memory.
>
> Jan looks like you originaly wrote the test, do you agree that this
> should go in now?

That's fine by me. As you said, the change in size doesn't matter that
much for the test.

>
> --
> Cyril Hrubis
> chrubis@suse.cz
>