aboutsummaryrefslogtreecommitdiff
path: root/libc/bionic/pthread_kill.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Make more pthread functions weak for native bridgeEvgeny Eltsin2019-09-251-0/+2
| | | | | | | These are using __pthread_internal_*. Test: run bionic-unit-tests on cuttlefish Change-Id: Idbb2503f03bd9f1f2a20fced34b734f573c1c0ad
* Pass caller names to __pthread_internal_find for better errors.Elliott Hughes2019-02-011-1/+1
| | | | | | | | | | | | | | | On http://b/122082295 we had this abort: 12-27 15:29:31.237 10222 10814 10848 F libc : invalid pthread_t 0xb1907960 passed to libc This wasn't super helpful. We can do better. Now you get something like this instead: 03-27 02:34:58.754 25329 25329 W libc : invalid pthread_t (0) passed to pthread_join Test: adb shell crasher Bug: http://b/123255692 Change-Id: I1d545665a233308480cc3747ec3120e2b6de0453
* Properly fail with ESRCH when pthread_killing an exited thread.Josh Gao2018-10-171-1/+3
| | | | | | | | Previously, we were callign tgkill(pid, 0, signal) instead, which would fail with EINVAL instead. Test: bionic-unit-tests Change-Id: I25b127dcf347e0223274502b0516a950b6c2093e
* Be more strict about using invalid `pthread_t`s.Elliott Hughes2017-02-131-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Revert "Remove the global thread list.""David James2017-02-021-1/+5
|\
| * Revert "Remove the global thread list."Elliott Hughes2017-02-021-1/+5
| | | | | | | | | | | | | | | | This reverts commit b0e8c565a622b5519e03d4416b0b5b1a5f20d7f5. Breaks swiftshader (http:/b/34883464). Change-Id: I7b21193ba8a78f07d7ac65e41d0fe8516940a83b
* | Merge "Remove the global thread list."Elliott Hughes2017-02-011-5/+1
|\|
| * Remove the global thread list.Elliott Hughes2017-01-071-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Add declaration of tgkill to signal.h.Josh Gao2017-01-051-2/+0
|/ | | | | | | | Expose a useful function that we've had since Jelly Bean. Bug: http://b/34111810 Test: TreeHugger Change-Id: Iaf3097f224c09b533f36050cf21394ba148007ad
* Let g_thread_list_lock only protect g_thread_list.Yabin Cui2015-03-231-13/+4
| | | | | | | | | 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
* Fix x86_64 build, clean up intermediate libraries.Elliott Hughes2013-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Fix raise(3) so it works in signal handlers.Elliott Hughes2013-02-211-1/+5
| | | | | | | | We could special-case raise(3) in non-threaded programs, but the more conservative course is to make pthread_kill(3) work in signal handlers at the cost of a race shared by other C libraries. Change-Id: I59fb23d03bdabf403435e731704b33acdf3e0234
* Fix pthreads functions that should return ESRCH.Elliott Hughes2013-02-191-0/+51
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