This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Linux: Use mmap instead of malloc in dirent/tst-getdents64


* Adhemerval Zanella:

> On 28/06/2019 05:49, Florian Weimer wrote:
>> malloc dirties the entire allocated memory region due to M_PERTURB
>> in the test harness.
>> 
>> 2019-06-28  Florian Weimer  <fweimer@redhat.com>
>> 
>> 	* sysdeps/unix/sysv/linux/tst-getdents64.c (large_buffer_checks):
>> 	Use mmap instead of malloc.  malloc with M_PERTURB writes to the
>> 	entire allocated memory range.
>
> LGTM.
>
> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

Thanks!

>> diff --git a/sysdeps/unix/sysv/linux/tst-getdents64.c b/sysdeps/unix/sysv/linux/tst-getdents64.c
>> index 24e77e04d8..8a28e6c67c 100644
>> --- a/sysdeps/unix/sysv/linux/tst-getdents64.c
>> +++ b/sysdeps/unix/sysv/linux/tst-getdents64.c
>> @@ -27,6 +27,7 @@
>>  #include <support/check.h>
>>  #include <support/support.h>
>>  #include <support/xunistd.h>
>> +#include <sys/mman.h>
>>  #include <unistd.h>
>>  
>>  /* Called by large_buffer_checks below.  */
>> @@ -53,8 +54,13 @@ large_buffer_checks (int fd)
>>    size_t large_buffer_size;
>>    if (!__builtin_add_overflow (UINT_MAX, 2, &large_buffer_size))
>>      {
>> -      char *large_buffer = malloc (large_buffer_size);
>> -      if (large_buffer == NULL)
>> +      int flags = MAP_ANONYMOUS | MAP_PRIVATE;
>> +#ifdef MAP_NORESERVE
>> +      flags |= MAP_NORESERVE;
>> +#endif
>> +      void *large_buffer = mmap (NULL, large_buffer_size,
>> +                                 PROT_READ | PROT_WRITE, flags, -1, 0);
>> +      if (large_buffer == MAP_FAILED)
>
> Should we really skip the test instead of using xmmap? The only case I think of
> that it might fail is if kernel can't allocate bookeeping memory for the page
> table itself, but I really think it unlikely (sanitizer usually allocates a
> lot of VMA as well).

MAP_NORESERVE is a misnomer; it does not do what it says.  It disables
the overcommit heuristics for vm.overcommit_memory=0, but not for
vm.overcommit_memory=2.  mmap can also fail due to resource limits on
address space, not residential memory.  So I think the code above is the
best we can do.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]