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

karnajit wangkhem karnajitw at gmail.com
Thu Oct 15 14:54:53 UTC 2020


Hi freebsd team,



While checking on a valgrind issue, I encountered the following mapping of
a simple test program on a freebsd-12.



Below is the procstat -v output I took by breaking on _rtld.



[Stable 12]

# procstat -v 76573

  PID              START                END PRT  RES PRES REF SHD FLAG  TP
PATH

<SNIP>

76573        0x800227000        0x800229000 rw-    1    1   1   0 ----- df

76573     0x7fffdffff000     0x7ffffffdf000 ---    0    0   0   0 -----
--                  <<< This ~511MB memory segment

76573     0x7ffffffdf000     0x7ffffffff000 rw-    1    1   1   0 ---D- df

76573     0x7ffffffff000     0x800000000000 r-x    1    1  99   0 ----- ph



[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?


Regards,

Karan


More information about the freebsd-hackers mailing list