about summary refs log tree commit diff
path: root/support/xthread.h
Commit message (Collapse)AuthorAgeFilesLines
* rwlock: Fix explicit hand-over (bug 21298)Carlos O'Donell2017-07-281-0/+8
| | | | | | | Without this fix, the rwlock can fail to execute the explicit hand-over in certain cases (e.g., empty critical sections that switch quickly between read and write phases). This can then lead to errors in how __wrphase_futex is accessed, which in turn can lead to deadlocks.
* nptl: Invert the mmap/mprotect logic on allocated stacks (BZ#18988)Adhemerval Zanella2017-06-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current allocate_stack logic for create stacks is to first mmap all the required memory with the desirable memory and then mprotect the guard area with PROT_NONE if required. Although it works as expected, it pessimizes the allocation because it requires the kernel to actually increase commit charge (it counts against the available physical/swap memory available for the system). The only issue is to actually check this change since side-effects are really Linux specific and to actually account them it would require a kernel specific tests to parse the system wide information. On the kernel I checked /proc/self/statm does not show any meaningful difference for vmm and/or rss before and after thread creation. I could only see really meaningful information checking on system wide /proc/meminfo between thread creation: MemFree, MemAvailable, and Committed_AS shows large difference without the patch. I think trying to use these kind of information on a testcase is fragile. The BZ#18988 reports shows that the commit pages are easily seen with mlockall (MCL_FUTURE) (with lock all pages that become mapped in the process) however a more straighfoward testcase shows that pthread_create could be faster using this patch: -- static const int inner_count = 256; static const int outer_count = 128; static void *thread1(void *arg) { return NULL; } static void *sleeper(void *arg) { pthread_t ts[inner_count]; for (int i = 0; i < inner_count; i++) pthread_create (&ts[i], &a, thread1, NULL); for (int i = 0; i < inner_count; i++) pthread_join (ts[i], NULL); return NULL; } int main(void) { pthread_attr_init(&a); pthread_attr_setguardsize(&a, 1<<20); pthread_attr_setstacksize(&a, 1134592); pthread_t ts[outer_count]; for (int i = 0; i < outer_count; i++) pthread_create(&ts[i], &a, sleeper, NULL); for (int i = 0; i < outer_count; i++) pthread_join(ts[i], NULL); assert(r == 0); } return 0; } -- On x86_64 (4.4.0-45-generic, gcc 5.4.0) running the small benchtests I see: $ time ./test real 0m3.647s user 0m0.080s sys 0m11.836s While with the patch I see: $ time ./test real 0m0.696s user 0m0.040s sys 0m1.152s So I added a pthread_create benchtest (thread_create) which check the thread creation latency. As for the simple benchtests, I saw improvements in thread creation on all architectures I tested the change. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu, sparc64-linux-gnu, and sparcv9-linux-gnu. [BZ #18988] * benchtests/thread_create-inputs: New file. * benchtests/thread_create-source.c: Likewise. * support/xpthread_attr_setguardsize.c: Likewise. * support/Makefile (libsupport-routines): Add xpthread_attr_setguardsize object. * support/xthread.h: Add xpthread_attr_setguardsize prototype. * benchtests/Makefile (bench-pthread): Add thread_create. * nptl/allocatestack.c (allocate_stack): Call mmap with PROT_NONE and then mprotect the required area.
* Bug 20116: Fix use after free in pthread_create()Carlos O'Donell2017-01-281-0/+6
| | | | | | | | | | | | | | | | | | The commit documents the ownership rules around 'struct pthread' and when a thread can read or write to the descriptor. With those ownership rules in place it becomes obvious that pd->stopped_start should not be touched in several of the paths during thread startup, particularly so for detached threads. In the case of detached threads, between the time the thread is created by the OS kernel and the creating thread checks pd->stopped_start, the detached thread might have already exited and the memory for pd unmapped. As a regression test we add a simple test which exercises this exact case by quickly creating detached threads with large enough stacks to ensure the thread stack cache is bypassed and the stacks are unmapped. Before the fix the testcase segfaults, after the fix it works correctly and completes without issue. For a detailed discussion see: https://www.sourceware.org/ml/libc-alpha/2017-01/msg00505.html
* nptl: Add tst-robust-forkFlorian Weimer2017-01-271-0/+9
|
* Update copyright dates with scripts/update-copyrights.Joseph Myers2017-01-011-1/+1
|
* resolv: Add beginnings of a libresolv test suiteFlorian Weimer2016-12-311-0/+1
|
* support: Introduce new subdirectory for test infrastructureFlorian Weimer2016-12-091-0/+61
The new test driver in <support/test-driver.c> has feature parity with the old one. The main difference is that its hooking mechanism is based on functions and function pointers instead of macros. This commit also implements a new environment variable, TEST_COREDUMPS, which disables the code which disables coredumps (that is, it enables them if the invocation environment has not disabled them). <test-skeleton.c> defines wrapper functions so that it is possible to use existing macros with the new-style hook functionality. This commit changes only a few test cases to the new test driver, to make sure that it works as expected.