Red Hat Bugzilla – Full Text Bug Listing
|Summary:||set_thread_area races kill/pthread_handle_sigcancel [linuxltfs]|
|Product:||Red Hat Enterprise Linux 3||Reporter:||John Reiser <jreiser>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||2.3.2-87||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-06-30 15:20:56 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description John Reiser 2003-09-13 12:38:35 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030902 Description of problem: There is a race in the way that linuxltfs uses set_thread_area() after clone(). With suitable delays, the new thread can get canceled before set_thread_area() takes effect. When this happens, the signal handler in the new thread, pthread_handle_sigcancel(), will get a SIGSEGV because it uses segment register %gs but the corresponding segment descriptor has not yet been setup by set_thread_area(). Version-Release number of selected component (if applicable): glibc-2.3.2-85 How reproducible: Sometimes Steps to Reproduce: 1. run testcases build-i686-linuxltfs/linuxthreads/tst-cancel2 or tst-cancel3, but provide a slowdown of 100:1 [one hundred to one] or more 2. 3. Actual Results: Attached partial strace of running tst-cancel2 under a memory-access checker [provides a slowdown as a side effect] shows that the fork()ed watchdog sends SIGRT_1 to a child thread before the child thread invokes set_thread_area(). Expected Results: Signals whose handler uses register %gs must not be sent to a thread that does not have set_thread_area() already setup. Additional info:
Comment 1 John Reiser 2003-09-13 12:40:34 EDT
Created attachment 94475 [details] strace -f tst-cancel2 [edited for brevity]
Comment 2 Jakub Jelinek 2003-09-14 16:28:13 EDT
I don't see the problem. Before DO_SET_THREAD_AREA, %gs is what the initial INIT_THREAD_SELF (, 0) chose and kernel tls_array in the kernel points to manager_thread. If SIGCANCEL arrives at this moment, pthread_handle_sigcancel should catch this (self == manager_thread) and do the right thing. Now DO_SET_THREAD_AREA calls set_thread_area syscall, changing tls_array from manager_thread to the actual thread descriptor. Whatever moment the signal arrives, pthread_handle_sigcancel should either see self == manager_thread or self == the_new_thread_descriptor, nothing else.
Comment 3 John Reiser 2003-09-15 10:05:05 EDT
OK; I did not understand the part about pthread_handle_sigcancel handling the situation in both cases (race won, race lost). This seems to mean that signal handlers cannot access thread-local storage under linuxltfs (hard to setup anyway [?], but does mean additional compatibility concerns for apps: "nptl app" will be unreliable under linuxltfs), and that signal handlers cannot call any pthread_* functions except pthread_handle_sigcancel.
Comment 4 Jakub Jelinek 2003-09-17 15:00:40 EDT
glibc-2.3.2-87 now does the self == manager_thread -> find self from stack, INIT_THREAD_SELF in signal handler wrappers too.