Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11

Konstantin Belousov kostikbel at gmail.com
Fri Oct 16 10:11:53 UTC 2020


On Fri, Oct 16, 2020 at 10:43:32AM +0530, karnajit wangkhem wrote:
> Thanks for the reply. It helped in my understanding.
> 
> Below is a sample code
> 
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <sys/mman.h>
> 
> int main()
> {
>   char *str = NULL;
>   str = (char *)mmap((void *)0x7fffdfffe000UL, 0x2000, PROT_READ |
> PROT_WRITE, MAP_FIXED | MAP_ANON, -1, 0);
>   if ((void *)str == (void *)MAP_FAILED) {
>     int err = errno;
>     printf("mmap failed. err (%s)\n", strerror(err));
>   } else {
>     memcpy(str, "Hello World", 12);
>     printf("str = %s\n", str);
>   }
> 
>   return 0;
> }
> 
> Now, the below code under valgrind will give
> - mmap failed. err (Invalid argument)
> 
> But, if we give control of this segment to the client program
> with VG_(am_change_ownership_v_to_c), then valgrind allows the client to do
> the following mmap.
> - str = Hello World
> 
> And, the resultant procstat result looks like this:
>  2382        0x7fbfff000        0x7fc001000 rwx    2    2   1   0 ----- df
>  2382     0x7fffdfffe000     0x7fffe0000000 rw-    0    0   0   0 ----- --
>    <<< Client mmap call
>  2382     0x7fffe0000000     0x7ffffffdf000 ---    0    0   0   0 ----- --
>      <<< 0x1000 bytes is taken away from the MAP_GUARD area
>  2382     0x7ffffffdf000     0x7ffffffff000 rw-    1    1   1   0 ---D- df
>  2382     0x7ffffffff000     0x800000000000 r-x    1    1 104   0 ----- ph
> 
> So, is it right for the application with or without valgrind to cross the
> above boundary, If that memory which the application reserved is just for
> normal application specific use?

You called mmap(2) with MAP_FIXED flag, which means that mmap must destroy
any mapping existing at the specified address, and create the requested
mapping instead.  This should work as far as the requested range fits into
the userspace virtual address space, and mapping object provides requested
permissions.

If valgrind does not emulate that behavior of MAP_FIXED correctly, it is
valgrind bug.

That said, application trying to mmap something at the guard holding the
stack grow area is most likely buggy.  Old libthr intentionally split main
thread' stack into stacks of the new threads, but this was changed.


More information about the freebsd-hackers mailing list