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