Never unmap memory reserved for RELRO file creation.

Never unmap memory reserved for RELRO file creation.

After loading a library with android_dlopen_ext and passing the flag
ANDROID_DLEXT_RESERVED_ADDRESS, a subsequent dlclose will unmap the
part of the reservation occupied by the library, but leave the
remainder of the reservation mapped. If we ourselves later unmap the
entire reservation, we may also unmap data from a thread that happened
to map into the hole created in our reservation by the dlclose unmap.
This is an unpleasant mmap/munmap threads race.

Because dlclose's unmap is opaque to us, we cannot readily unmap the
remaining portions of our reservation because we do not know exactly
where they now start and end. However, we only dlclose on relro
creation, and this occurs just once, on browser process startup. By
leaving these remaining reservation portions mapped but unused, we
'waste' a few Mb of virtual address space, but crucially we do not
waste actual memory because these addresses are never used by anything.

Implemented by explicitly releasing the reservation scoped mapping
*before* the dlclose call in relro creation.

Also, make failure to trim address space on library load for run a
non-fatal error (warning). Failure to munmap can really only be due
to coding error. And even if it does fail the library code can and
will still run okay, albeit again with minor loss of some virtual
address space that we otherwise might have recovered.

BUG=568880
Review URL: https://codereview.chromium.org/1583093007

Cr-Commit-Position: refs/heads/master@{#370015}
(cherry picked from commit b857f7676bc16665ca86d81db877dc11094bcb7a)

Committed: https://chromium.googlesource.com/chromium/src/+/3547a47a96f4af6a7fb78e50cc86e3f812783438

[simonb (inactive), 2016-01-20 15:04:51]

Description was changed from

==========
Never unmap memory reserved for RELRO file creation.

After loading a library with android_dlopen_ext and passing the flag
ANDROID_DLEXT_RESERVED_ADDRESS, a subsequent dlclose will unmap the
part of the reservation occupied by the library, but leave the
remainder of the reservation mapped. If we ourselves later unmap the
entire reservation, we may also unmap data from a thread that happened
to map into the hole created in our reservation by the dlclose unmap.
This is an unpleasant mmap/munmap threads race.

Because dlclose's unmap is opaque to us, we cannot readily unmap the
remaining portions of our reservation because we do not know exactly
where they now start and end. However, we only dlclose on relro
creation, and this occurs just once, on browser process startup. By
leaving these remaining reservation portions mapped but unused, we
'waste' a few Mb of virtual address space, but crucially we do not
waste actual memory because these addresses are never used by anything.

Implemented by explicitly releasing the reservation scoped mapping
*before* the dlclose call in relro creation.

Also, make failure to trim address space on library load for run a
non-fatal error (warning). Failure to munmap can really only be due
to coding error. And even if it does fail the library code can and
will still run okay, albeit again with minor loss of some virtual
address space that we otherwise might have recovered.

BUG=568880

Review URL: https://codereview.chromium.org/1583093007

Cr-Commit-Position: refs/heads/master@{#370015}
(cherry picked from commit b857f7676bc16665ca86d81db877dc11094bcb7a)
==========

to

==========
Never unmap memory reserved for RELRO file creation.

After loading a library with android_dlopen_ext and passing the flag
ANDROID_DLEXT_RESERVED_ADDRESS, a subsequent dlclose will unmap the
part of the reservation occupied by the library, but leave the
remainder of the reservation mapped. If we ourselves later unmap the
entire reservation, we may also unmap data from a thread that happened
to map into the hole created in our reservation by the dlclose unmap.
This is an unpleasant mmap/munmap threads race.

Because dlclose's unmap is opaque to us, we cannot readily unmap the
remaining portions of our reservation because we do not know exactly
where they now start and end. However, we only dlclose on relro
creation, and this occurs just once, on browser process startup. By
leaving these remaining reservation portions mapped but unused, we
'waste' a few Mb of virtual address space, but crucially we do not
waste actual memory because these addresses are never used by anything.

Implemented by explicitly releasing the reservation scoped mapping
*before* the dlclose call in relro creation.

Also, make failure to trim address space on library load for run a
non-fatal error (warning). Failure to munmap can really only be due
to coding error. And even if it does fail the library code can and
will still run okay, albeit again with minor loss of some virtual
address space that we otherwise might have recovered.

BUG=568880

Review URL: https://codereview.chromium.org/1583093007

Cr-Commit-Position: refs/heads/master@{#370015}
(cherry picked from commit b857f7676bc16665ca86d81db877dc11094bcb7a)

Committed:
https://chromium.googlesource.com/chromium/src/+/3547a47a96f4af6a7fb78e50cc86...
==========

[simonb (inactive), 2016-01-20 15:04:53]

Committed patchset #1 (id:1) manually as
3547a47a96f4af6a7fb78e50cc86e3f812783438.