Static variable initialization calls pthread_mutex_lock() and may lead to
deadlock if should_trace() is called in pthread_mutex_lock context.
Here is a stack of blocked init process:
__cxa_guard_acquire ->
should_trace ->
bionic_trace_begin ->
__pthread_mutex_lock_with_timeout ->
__cxa_guard_release ->
should_trace ->
bionic_trace_begin ->
__pthread_mutex_lock_with_timeout ->
mutex::lock ->
LogMessage::~LogMessage
......
So we need to move it out
Test: 1 Compiled and booted.
2 Reboot pressure test for more than 30000 times.
Change-Id: I8d97745161f1aa8942b63338208ea74830768ae1
Signed-off-by: Wei Li <sirius.liwei@huawei.com>
Signed-off-by: Jinguang Dong <dongjinguang@huawei.com>
Bug: http://b/29177606
Test: run bionic-unit-tests on walleye.
Test: run bionic-unit-tests-glibc on host.
Change-Id: Iac349284aa73515f384e7509445f87434757f59e
There were a bunch more unreasonable/incorrect ones, but these ones
seemed legit. Nothing very interesting, though.
Bug: N/A
Test: ran tests, benchmarks
Change-Id: If66971194d4a7b4bf6d0251bedb88e8cdc88a76f
This is also slightly faster for the no VDSO case (56ns vs 66ns).
Bug: N/A
Test: ran tests, benchmarks
Change-Id: I2b0edd06ee6942eb57c32678279278a53ca5ee9b
Introduce new flag to mark soinfo as TLS_NODELETE when
there are thread_local dtors associated with dso_handle
belonging to it.
Test: bionic-unit-tests --gtest_filter=dl*
Test: bionic-unit-tests-glibc --gtest_filter=dl*
Bug: https://github.com/android-ndk/ndk/issues/360
Change-Id: I724ef89fc899788f95c47e6372c38b3313f18fed
Make the cost of strto<signed> closer to the cost of strto<unsigned>
by removing an `if` from the inner loop. Previously a signed conversion
cost 10ns more than an unsigned one.
After:
BM_inttypes_strtoimax 81 ns 81 ns 8603362
BM_inttypes_strtoumax 78 ns 78 ns 8967174
BM_stdlib_strtol 81 ns 81 ns 8685537
BM_stdlib_strtoll 81 ns 81 ns 8685481
BM_stdlib_strtoul 78 ns 78 ns 8962569
BM_stdlib_strtoull 78 ns 78 ns 8972023
Bug: N/A
Test: ran tests, benchmarks
Change-Id: I72dd5499427b6a940bd94c4d6f727f7efe134d7e
There are no meaningful changes here, just a minimal conversion to two
C++ templates to make further changes easier.
Bug: N/A
Test: ran tests, benchmarks
Change-Id: I958fbf17a85f19dd8f17bfb4bbb9314d220daa3b
Reinitializing system properties can result in crashes later in the
program, and is generally not recommended or even supported. This
change moves the actual logic for system properties into a class that
can be tested in isolation, without reinitializing the actual system
property area used in libc.
Bug: 62197783
Test: boot devices, ensure properties work
Test: system property unit tests and benchmarks
Change-Id: I9ae6e1b56c62f51a4d3fdb5b62b8926cef545649
Add a new stress test, and fix the code to pass it. We need to ensure that
we reset signal handlers for caught signals before unblocking signals in
the child, we need to ensure that this happens even if you haven't passed
a pthread_spawn_attr_t, and we need to ensure that this happens if you
pass in an empty sigdefault set.
Bug: http://b/68707996
Test: ran tests
Change-Id: I348e9b17b1bdf221591da42c0ada133d98471d66
When a vdso call falls back to making a regular system call, the inline
code for the system call doesn't know about errno and just leaves the
usual kernel result to be translated. Add the missing translation.
Also fix the defaults for non-vdso systems so we actually take the
fallback path (and so avoid unintentionally doing the errno translation
twice in those cases).
Bug: http://b/69626243
Test: ran new tests from http://b/63737556
Change-Id: If379632ea2e059e3d3bc3ff41bf3608dc05fb0a3
Currently, getpwnam, getpwent, etc return successfully for any uid
from AID_APP_START (10000) to AID_USER_OFFSET (100000) for each user.
This is not correct however, as only specific ranges above
AID_APP_START are reserved as valid ranges. This change corrects this.
This is particularly important as the newly added AID_OVERFLOWUID is
65534, which is above AID_APP_START but not in any reserved range,
collided with the faulty returned values.
Bug: 69119022
Bug: 69128408
Test: pwd/grp bionic unit tests
Change-Id: I3dae97a90597915fa30a88fe27cda88b107e9c35
I don't think there's any observable difference, but this is certainly
simpler.
Bug: http://b/68707996
Test: ran tests
Change-Id: Id9e1a7d40533c90d073ebf391a72bbdfe79627de
system_properties.cpp is a little bit unmanageable in its current
form, and is overdue for a refactoring into more clearly defined
components.
Of particular interest, is creating of a Contexts interface that
handles mapping of system property name -> SEContext and its
associated prop_area, and creating two classes that implement the
current and legacy functionality. This is needed as there will likely
be a third even newer way to do this mapping.
Bug: 36001741
Test: boot bullhead, system property unit tests
Change-Id: Ie75ec6fea1a95f90813918f54669d533e51327c6
At the cost of two flag bits for what POSIX thinks should be a boolean
choice, plus somewhat confusing behavior from pthread_attr_getinheritsched
depending on when you call it/what specific scheduler attributes you've
set in the pthread_attr_t, we can emulate the old behavior exactly and
prevent annoying SELinux denial spam caused by calls to sched_setscheduler.
Bug: http://b/68391226
Test: adb logcat on boot contains no sys_nice avc denials
Change-Id: I4f759c2c4fd1d80cceb0912d7da09d35902e2e5e
To make it easier for Native Bridge implementations
to override these symbols.
Bug: http://b/67993967
Test: make
Change-Id: I4c53e53af494bca365dd2b3305ab0ccc2b23ba44
Move all the new checks over to the existing __fortify_fatal.
Bug: http://b/67455242
Test: ran tests
Change-Id: Idb899c58c32d52d3b423caf1a91feb7defcba9b3
Historically, Android defaulted to EXPLICIT but with a special case
because SCHED_NORMAL/priority 0 was awkward. Because the code couldn't
actually tell whether SCHED_NORMAL/priority 0 was a genuine attempt to
explicitly set those attributes (because the parent thread is SCHED_FIFO,
say) or just because the pthread_attr_t was left at its defaults.
Now we support INHERIT, we could call sched_getscheduler to see whether
we actually need to call sched_setscheduler, but since the major cost
is the fixed syscall overhead, we may as well just conservatively
call sched_setscheduler and let the kernel decide whether it's a
no-op. (Especially because we'd then have to add both sched_getscheduler
and sched_setscheduler to any seccomp filter.)
Platform code (or app code that only needs to support >= P) can actually
add a call to pthread_attr_setinheritsched to say that they just want
to inherit (if they know that none of their threads actually mess with
scheduler attributes at all), which will save them a sched_setscheduler
call except in the doubly-special case of SCHED_RESET_ON_FORK (which we
do handle).
An alternative would be "make pthread_attr_setschedparams and
pthread_attr_setschedprio set EXPLICIT and change the platform default
to INHERIT", but even though I can only think of weird pathological
examples where anyone would notice that change, that behavior -- of
pthread_attr_setschedparams/pthread_attr_setschedprio overriding an
earlier call to pthread_attr_setinheritsched -- isn't allowed by POSIX
(whereas defaulting to EXPLICIT is).
If we have a lot of trouble with this change in the app compatibility
testing phase, though, we'll want to reconsider this decision!
-*-
This change also removes a comment about setting the scheduler attributes
in main_thread because we'd have to actually keep them up to date,
and it's not clear that doing so would be worth the trouble.
Also make async_safe_format_log preserve errno so we don't have to be
so careful around it.
Bug: http://b/67471710
Test: ran tests
Change-Id: Idd026c4ce78a536656adcb57aa2e7b2c616eeddf
These are still needed for backwards compatibility with code built by old
versions of the NDK, but we don't need to pollute the headers with them.
Also lose the hand-written code for these. The compiler-generated code
is either the same or better, and no new code is calling these functions
anyway.
Bug: N/A
Test: ran tests
Change-Id: Ib01ad9805034433e0105aec882608cc8e6526f78
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
Add a static library containing the non-pthread dependent parts of
libc.
Bug: http://b/64400027
Test: sailfish boots
Test: bionic-unit-tests32/64, no new failures
Test: bionic-unit-tests-static32/64, no new failures
Change-Id: I93dc3811acddad7936d11b369b98cefd945ee2d5
Add all the missing <netdb.h> functions.
Also fix getservbyport to handle a null protocol correctly.
Also fix getservbyname/getservbyport to not interfere with getservent.
Also fix endservent to reset getservent iteration.
Also reduce unnecessary differences from upstream NetBSD sethostent.c.
The servent implementation is still horrific, and we should
probably support protoent too so that debugging tools can use
getprotobyname/getprotobynumber.
Bug: N/A
Test: ran tests
Change-Id: I639108c46df0a768af297cf3bbce857cb1bef9d9
