[LTP] [PATCH] syscalls/mmap21: Add new test for mmap's ENOMEM case

Richard Palethorpe rpalethorpe@suse.de
Fri Sep 8 11:45:20 CEST 2023


Hello,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> To be more precise in this test and checking for ENOMEM on exact mapping
>> when limit is crossed, I could only think of counting the existing
>> mappings from /proc/$pid/maps and counting the remaining possible
>> mappings. Is there any better approach if we want to test this for exact
>> case?
>
> If you want to check that we managed to create exactly the amount of
> mappings in this limit, this would be a sensible way to do that.
>
> However beware that this also depends on the overcommit settings. If

yes, and perhaps this can be effected by CGroups and resource limit
settings as well. I would assume there are lots of limits that could
effect the test.

> kernel is not set to overcommit and if the size of the memory needed to
> cross the maximal number of mappings would exceed available memory you
> would get ENOMEM before you manage to hit the limit. With overcommit
> enabled you can create mappings as long as the kernel has enough memory
> to hold the vma structures.
>
> At my system the limit is set to 65530 which on 4k page size would
> consume around 300MB, which does not seem to be much, but may still fail
> on small embedded boards with disabled overcommit. So either we try to
> set the limit to a lower value for the duration of the test, or allow
> the mmap() to fail sooner if we find that available memory is close to
> or smaller than number of mappings multiplied by page size.

That seems like the safest option without enumerating all of the
possible limits.

Setting to changes requested.

-- 
Thank you,
Richard.


More information about the ltp mailing list