[LTP] [PATCH 3/3] mmap24: add test for MAP_32BIT address limit

[Petr Vorel]

Hi Andrea,

...
> > BTW I was wondering if I can get this failing when running on VM with really
> > small RAM, but even with 249 MB I get get mapped 928 MB (or 960 MB when I run
> > with -i):

> > mmap24.c:81: TPASS: Mapped 928 MB across 29 chunks within 2GB before ENOMEM

> > What am I missing?

> Thanks for checking, I didn't verify 32-bits indeed..

> I found the reason and it's really tricky. In arch/x86/kernel/sys_x86_64.c,
> MAP_32BIT forces the mapping range to:

> 	begin = 0x40000000 (1 GB)
> 	end = 0x80000000 (2 GB)

+1. That might explain the different value on mmap23.c as well.

> Which is 1GB max.

> And probably the reason why you can "map" 928 MB in a short memory system
> is becasuee you are actually seeing virtual memory allocation. The test
> is touching just 2 pages instead of all:

> 	((char *)addr)[0] = 'a';
> 	((char *)addr)[CHUNK_SZ - 1] = 'z';

> can you try to apply a memset() for the whole allocation and see what
> happens? The only problem if I use this method, tho, is that memory might
> be swapped out.

If you mean something like code below, the result is the same (+ of course big
slowdown).

+++ testcases/kernel/syscalls/mmap/mmap24.c
@@ -67,8 +67,9 @@ static void run(void)
                        return;
                }

-               ((char *)addr)[0] = 'a';
-               ((char *)addr)[CHUNK_SZ - 1] = 'z';
+               for (size_t j = 0; j < CHUNK_SZ; j++) {
+                       ((char *)addr)[j] = 'a';
+               }

                addrs[num_chunks++] = addr;
        }

> I will send a new version with PROT_NONE that is allocating virtual
> pages and changing a bit the logic of the final check.

+1

Kind regards,
Petr