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

[Paul Floyd]

> On 15 Oct 2020, at 16:54, karnajit wangkhem <karnajitw at gmail.com> wrote:
> 
> Hi freebsd team,
> 
> While checking on a valgrind issue, I encountered the following mapping of
> a simple test program on a freebsd-12.

;-)


> [Stable 11]
> 
> # procstat -v 85507
> 
>  PID              START                END PRT  RES PRES REF SHD FLAG TP
> PATH
> 
> <SNIP>
> 
> 85507        0x800820000        0x800822000 rw-    1    1   1   0 ---- df
> 85507     0x7ffffffdf000     0x7ffffffff000 rw-    1    1   1   0 ---D df
> 85507     0x7ffffffff000     0x800000000000 r-x    1    1 104   0 ---- ph
> 
> There is an extra ~511MB reserved mmap area starting at 0x7fffdffff000 in
> stable 12. Could you please give me an insight of what this is for and is
> it ok for a userspace program to modify this mapping?
> 
> The reason is that our applications reserve some fixed memory that
> crosses/modify the above region. As this mapping was not called by the
> client program, valgrind had taken control of it. So, I have to decide
> whether to give the control to the client and allow modifications(mprotect,
> unmap, mmap, etc) on this memory segment or logically(not mandatorily) a
> client program should be allowed to modify this area?


This extra memory is the MAP_GUARD, which was introduced in FreeBSD 10.4
and changed to be a large zone in FreeBSD 11.1.

If I understand correctly, it’s a kind of super-sized guard page for the stack.
There are more details in the mmap man page.

If you run Valgrind with the -d option it will print a table of the memory mapping
(Prefixed with ‘aspacem’ for Address Space Manager). If you want to see some
more Valgrind details, see aspacemgr-linux.c from line 1646 (despite the name
it's used by all supported platforms).

A+
Paul