I'll land another patch that makes this required once I've fixed up
all the callers.
Bug: https://github.com/android/ndk/issues/2014
Test: treehugger
Change-Id: I62b9fdd3174f37d33f01c27f7f4e9134f6d9df6e
These are padding pages are only needed to layout the ELF to be
compatible with max-page-size. They are zero-filled (holes) and
can be dropped from the page cache.
The madvise() here is a special case that also serves to hint to the
kernel what part of the segment is padding.
For example the kernel then shows these padding regions as PROT_NONE
VMAs (labeled [page size compat]) in /proc/*/maps.
Note: This doesn't use backing vm_area_structs, so doesn't consume
additional slab memory.
Before:
❯ cf-adb shell cat /proc/1/maps | grep -A1 'libbase.so$'
7f8d13600000-7f8d13614000 r--p 00000000 fe:09 21909460 /system/lib64/libbase.so
7f8d13614000-7f8d13638000 r-xp 00014000 fe:09 21909460 /system/lib64/libbase.so
7f8d13638000-7f8d1363c000 r--p 00038000 fe:09 21909460 /system/lib64/libbase.so
7f8d1363c000-7f8d1363d000 rw-p 0003c000 fe:09 21909460 /system/lib64/libbase.so
Segments appear extended in /proc/<pid>/maps
After:
❯ cf-adb shell cat /proc/1/maps | grep -A1 'libbase.so$'
7f3650043000-7f3650054000 r--p 00000000 fe:09 21906900 /system/lib64/libbase.so
7f3650054000-7f3650057000 ---p 00000000 00:00 0 [page size compat]
7f3650057000-7f3650079000 r-xp 00014000 fe:09 21906900 /system/lib64/libbase.so
7f3650079000-7f365007b000 ---p 00000000 00:00 0 [page size compat]
7f365007b000-7f365007c000 r--p 00038000 fe:09 21906900 /system/lib64/libbase.so
7f365007c000-7f365007f000 ---p 00000000 00:00 0 [page size compat]
7f365007f000-7f3650080000 rw-p 0003c000 fe:09 21906900 /system/lib64/libbase.so
Segments maintain PROT_NONE gaps ("[page size compat]") for app
compatiblity but these are not backed by actual slab VMA memory.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Test: Manual - Launch Free Fire Chaos app
Change-Id: Ic50540e247b4294eb08f8cf70e74bd2bf6606684
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
It has been found that some existing apps have implicit dependencies on
the address ranges in /proc/*/maps. Since segment extension changes the
range of the LOAD segment VMAs some of these apps crash, either by
SIGBUS or in yet unidentified ways.
Only perform the segment extension optimization if the kernel has the
necessary mitigations to ensure app compatibility.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Test: Manual - Launch Free Fire Chaos app
Change-Id: I5b03b22c4a468f6646750a00942cc2d57f43d0de
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Loader segment extension was introduced to fix kernel slab memory
regressions in page-agnostic Android. This reression was due to required
VMAs for the gap VMAs that exist when the elf-max-page-size >
runtime-page-size.
This issue already existed for some libraries like libart.so and
libhwui.so which use 2mB alignment to make use of THPs (transparent huge
pages).
Later it was found that this optimization could break in-field apps due
to dependencies and the address ranges in /proc/*/[s]maps.
To avoid breaking the in-field apps, the kernel can work around the
compatibility issues if made aware of where the padding regions exist.
However, the kernel can only represent padding for p_align up to 64KiB.
This is because the kernel uses 4 available bits in the vm_area_struct
to represent padding extent; and so cannot enable mitigations to avoid
breaking app compatibility for p_aligns > 64KiB.
For ELFs with p_align > 64KiB, don't do segment extension, to avoid issues
with app compatibility -- these ELFs already exist with gap mappings
and are not part of the page size transition VMA slab regression.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Test: Manual - Launch Free Fire Chaos app
Change-Id: Id4dcced4632dce67adab6348816f85847ce1de58
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Failure to add a property should be rare, so log the specific
failure to aid in debugging.
Bug: http://b/322714325
Change-Id: I9461428f16d7d04d5aceb910a5cf1c928cfe9da2
The malloc_not_svelte product variable has been removed and is
replaced by malloc_low_memory. This switches the sense of the
Test: Verified scudo config is used by default.
Test: Verified Android GO config uses the jemalloc low memory config.
Test: Verified that the default config on oriole produces the exact same
Test: libc.so with and without this change.
Change-Id: I48085fa6c2dcf5c61f847ef1f15c38653d1f7214
The optional block size for the /proc filesystem is set to page size.
The tests must reflect the same.
Bug: 315510913
Change-Id: Ifccf833829b4ea4ff9c7d375208124cdc43af04a
Change the comment to explain _why_ we're resolving the path, get
rid of unnecessarily explicit strlen() calls, and make it clearer
that result.path is unconditionally initialized; it's just the
specific content that varies.
Change-Id: Iffbd5efc2eafd56e3efa3c0aaf7c191e6bb66a04
This attribute had been commented out since it was first
committed a decade ago. No-one's going to chase down arm32-only
trivia like that before arm32 and x86 are removed as obsolete...
Change-Id: I8e29d16657b3f4ce379e65732d747f969ea31dae
Fix the issue if link for an symlink that point to an relative path
cause the linker can not find the right absolute path.
For example:
lrwxr-xr-x 1 root shell 13 2009-01-01 08:00 /system/bin/app_process -> app_process64
the '/system/bin/app_process' is symlinked to 'app_process64' and will be failed.
if the 'exe_to_load' is null and also failed when stat '/proc/self/exe'
will entered this path.
Without Patch:
[ Linking executable "app_process64" ]
linker: CANNOT LINK EXECUTABLE "/system/bin/app_process": library "libnativeloader.so" not found: needed by main executable
With Patch:
[ Linking executable "/system/bin/app_process64" ]
[ Using config section "system" ]
[ Jumping to _start (0x75593c3000)... ]
Test: Manual - Run app_process (symlinked to app_process64)
Change-Id: Iacd0a810a679e8d55d68d7e4c84f0e5e4f276b14
Signed-off-by: chenxinyuanchen <chenxinyuanchen@xiaomi.com>
Signed-off-by: chenxinyuanchen <chenxinyuanchen@xiaomi.corp-partner.google.com>
We should just be able to use __builtin_umull_overflow now, which expects
unsigned long parameters. We don't need __builtin_umul_overflow (which expects
unsigned ints) because Bionic is LP64 or ILP32, so for ILP32
sizeof(size_t) == sizeof(unsigned long),
so __builtin_umull_overflow will work for either ILP32 or LP64.
Test: mm
Change-Id: I872491731bca05e561767f8bfeda4c6704e10ccb
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
While studying the implementation of POSIX pthread_rwlock* functions, I noticed
that two functions were marked __always_inline twice. "They must really mean it
this time."
Also add back `inline` keyword to one other usage of __always_inline to be
consistent with other uses of __always_inline throughout the codebase.
Change-Id: Ibf9eaed5fc9fd03afcdd969cff82dec71a8ce30f
