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

[Andrea Cervesato via ltp <ltp@lists.linux.it>]

> Hi Andrea,
> 
> > Add a test verifying that mmap() with the MAP_32BIT flag restricts
> > mappings to the first 2GB of address space and fails with ENOMEM
> > when the 32-bit address space is exhausted without falling back to
> > higher addresses.
> 
> Thanks!
> 
> ...
> > +++ b/testcases/kernel/syscalls/mmap/mmap24.c
> ...
> > +
> > +		if ((unsigned long)addr + CHUNK_SZ > ADDR_LIMIT) {
> > +			tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
> %zu is wrong on 32 bit.
> 
> ../../../../include/tst_test.h:75:55: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 6 has type ‘long unsigned int’ [-Wformat=]
>    75 |                 tst_res_(__FILE__, __LINE__, (ttype), (arg_fmt), ##__VA_ARGS__);\
>       |                                                       ^~~~~~~~~
> mmap24.c:63:25: note: in expansion of macro ‘tst_res’
>    63 |                         tst_res(TFAIL, "mapping at %p + %zu exceeds 2GB limit",
>       |                         ^~~~~~~

+1

> 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)

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.

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

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp