Bug 104368 - set_thread_area races kill/pthread_handle_sigcancel [linuxltfs]
set_thread_area races kill/pthread_handle_sigcancel [linuxltfs]
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-13 12:38 EDT by John Reiser
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.2-87
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-30 15:20:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace -f tst-cancel2 [edited for brevity] (4.50 KB, text/plain)
2003-09-13 12:40 EDT, John Reiser
no flags Details

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.