dff08ced5685a0d1adb0ef875a15caca99556e1e |
|
16-Oct-2017 |
Elliott Hughes <enh@google.com> |
Add pthread_setschedprio. Bug: http://b/26204555 Test: ran tests Change-Id: Ic34062b9b6036a1ce2642a069514bab48a893338
|
11859d467c035081f8acafeaf0184b670cd41c48 |
|
14-Feb-2017 |
Elliott Hughes <enh@google.com> |
Be more strict about using invalid `pthread_t`s. Another release, another attempt to remove the global thread list. But this time, let's admit that it's not going away. We can switch to using a read/write lock for the global thread list, and to aborting rather than quietly returning ESRCH if we're given an invalid pthread_t. This change affects pthread_detach, pthread_getcpuclockid, pthread_getschedparam/pthread_setschedparam, pthread_join, and pthread_kill: instead of returning ESRCH when passed an invalid pthread_t, if you're targeting O or above, they'll abort with the message "attempt to use invalid pthread_t". Note that this doesn't change behavior as much as you might think: the old lookup only held the global thread list lock for the duration of the lookup, so there was still a race between that and the dereference in the caller, given that callers actually need the tid to pass to some syscall or other, and sometimes update fields in the pthread_internal_t struct too. (This patch replaces such users with calls to pthread_gettid_np, which at least makes the TOCTOU window smaller.) We can't check thread->tid against 0 to see whether a pthread_t is still valid because a dead thread gets its thread struct unmapped along with its stack, so the dereference isn't safe. Taking the affected functions one by one: * pthread_getcpuclockid and pthread_getschedparam/pthread_setschedparam should be fine. Unsafe calls to those seem highly unlikely. * Unsafe pthread_detach callers probably want to switch to pthread_attr_setdetachstate instead, or using pthread_detach(pthread_self()) from the new thread's start routine rather than doing the detach in the parent. * pthread_join calls should be safe anyway, because a joinable thread won't actually exit and unmap until it's joined. If you're joining an unjoinable thread, the fix is to stop marking it detached. If you're joining an already-joined thread, you need to rethink your design. * Unsafe pthread_kill calls aren't portably fixable. (And are obviously inherently non-portable as-is.) The best alternative on Android is to use pthread_gettid_np at some point that you know the thread to be alive, and then call kill/tgkill directly. That's still not completely safe because if you're too late, the tid may have been reused, but then your code is inherently unsafe anyway. Bug: http://b/19636317 Test: ran tests Change-Id: I0372c4428e8a7f1c3af5c9334f5d9c25f2c73f21
|
bcb152903a26269e2c8ada3b27c787ae875f8812 |
|
07-Feb-2017 |
Elliott Hughes <enh@google.com> |
Revert "Stop checking the global thread list in several trivial cases." This reverts commit f5a4992b7186c01b98cb9400b2b5b490805a87bb. Breaks OMX_ImgEnc in cameraserver (http://b/35088254). Change-Id: I6dcf12706a184b0b8b72451584567a42dfa1bb4f
|
f5a4992b7186c01b98cb9400b2b5b490805a87bb |
|
06-Feb-2017 |
Elliott Hughes <enh@google.com> |
Stop checking the global thread list in several trivial cases. Since removing the global thread is hard, let's take the different groups of functions individually. The existing code was racy anyway, because the thread might still be on the list but have exited (leaving tid == 0). Bug: http://b/19636317 Test: ran tests Change-Id: Icc0986ff124d5f9b8a653edf718c549d1563973b
|
7484c21c4c352a2200d94939fabc10d1bd3f0723 |
|
02-Feb-2017 |
Elliott Hughes <enh@google.com> |
Revert "Remove the global thread list." This reverts commit b0e8c565a622b5519e03d4416b0b5b1a5f20d7f5. Breaks swiftshader (http:/b/34883464). Change-Id: I7b21193ba8a78f07d7ac65e41d0fe8516940a83b
|
b0e8c565a622b5519e03d4416b0b5b1a5f20d7f5 |
|
04-Jan-2017 |
Elliott Hughes <enh@google.com> |
Remove the global thread list. Another release, another attempt to fix this bug. This change affects pthread_detach, pthread_getcpuclockid, pthread_getschedparam/pthread_setschedparam, pthread_join, and pthread_kill: instead of returning ESRCH when passed an invalid pthread_t, they'll now SEGV. Note that this doesn't change behavior as much as you might think: the old lookup only held the global thread list lock for the duration of the lookup, so there was still a race between that and the dereference in the caller, given that callers actually need the tid to pass to some syscall or other, and sometimes update fields in the pthread_internal_t struct too. We can't check thread->tid against 0 to see whether a pthread_t is still valid because a dead thread gets its thread struct unmapped along with its stack, so the dereference isn't safe. Taking the affected functions one by one: * pthread_getcpuclockid and pthread_getschedparam/pthread_setschedparam should be fine. Unsafe calls to those seem highly unlikely. * Unsafe pthread_detach callers probably want to switch to pthread_attr_setdetachstate instead, or using pthread_detach(pthread_self()) from the new thread's start routine rather than doing the detach in the parent. * pthread_join calls should be safe anyway, because a joinable thread won't actually exit and unmap until it's joined. If you're joining an unjoinable thread, the fix is to stop marking it detached. If you're joining an already-joined thread, you need to rethink your design. * Unsafe pthread_kill calls aren't portably fixable. (And are obviously inherently non-portable as-is.) The best alternative on Android is to use pthread_gettid_np at some point that you know the thread to be alive, and then call kill/tgkill directly. That's still not completely safe because if you're too late, the tid may have been reused, but then your code is inherently unsafe anyway. If we find too much code is still broken, we can come back and disable the global thread list lookups for anything targeting >= O and then have another go at really removing this in P... Bug: http://b/19636317 Test: N6P boots, bionic tests pass Change-Id: Ia92641212f509344b99ee2a9bfab5383147fcba6
|
673b15e4ee2c6d99b150aedddc0f389e29f98e1b |
|
19-Mar-2015 |
Yabin Cui <yabinc@google.com> |
Let g_thread_list_lock only protect g_thread_list. As glibc/netbsd don't protect access to thread struct members by a global lock, we don't want to do it either. This change reduces the responsibility of g_thread_list_lock to only protect g_thread_list. Bug: 19636317 Change-Id: I897890710653dac165d8fa4452c7ecf74abdbf2b
|
c3f114037dbf028896310609fd28cf2b3da99c4d |
|
30-Oct-2013 |
Elliott Hughes <enh@google.com> |
<pthread.h> fixes and pthread cleanup. <pthread.h> was missing nonnull attributes, noreturn on pthread_exit, and had incorrect cv qualifiers for several standard functions. I've also marked the non-standard stuff (where I count glibc rather than POSIX as "standard") so we can revisit this cruft for LP64 and try to ensure we're compatible with glibc. I've also broken out the pthread_cond* functions into a new file. I've made the remaining pthread files (plus ptrace) part of the bionic code and fixed all the warnings. I've added a few more smoke tests for chunks of untested pthread functionality. We no longer need the libc_static_common_src_files hack for any of the pthread implementation because we long since stripped out the rest of the armv5 support, and this hack was just to ensure that __get_tls in libc.a went via the kernel if necessary. This patch also finishes the job of breaking up the pthread.c monolith, and adds a handful of new tests. Change-Id: Idc0ae7f5d8aa65989598acd4c01a874fe21582c7
|
eb847bc8666842a3cfc9c06e8458ad1abebebaf0 |
|
10-Oct-2013 |
Elliott Hughes <enh@google.com> |
Fix x86_64 build, clean up intermediate libraries. The x86_64 build was failing because clone.S had a call to __thread_entry which was being added to a different intermediate .a on the way to making libc.so, and the linker couldn't guarantee statically that such a relocation would be possible. ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC This patch addresses that by ensuring that the caller and callee end up in the same intermediate .a. While I'm here, I've tried to clean up some of the mess that led to this situation too. In particular, this removes libc/private/ from the default include path (except for the DNS code), and splits out the DNS code into its own library (since it's a weird special case of upstream NetBSD code that's diverged so heavily it's unlikely ever to get back in sync). There's more cleanup of the DNS situation possible, but this is definitely a step in the right direction, and it's more than enough to get x86_64 building cleanly. Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4
|
9d23e04c43dbb8480bea8be28b8a2f37423bec49 |
|
16-Feb-2013 |
Elliott Hughes <enh@google.com> |
Fix pthreads functions that should return ESRCH. imgtec pointed out that pthread_kill(3) was broken, but most of the other functions that ought to return ESRCH for invalid/exited threads were equally broken. Change-Id: I96347f6195549aee0c72dc39063e6c5d06d2e01f
|