Re: linuxthread race condition

[Andreas Schwab <schwab at suse dot de>]

Wolfram Gloger <wmglo@dent.med.uni-muenchen.de> writes:

|> > There is a race condition in linuxthreads during thread creation on
|> > architectures that use a dedicated thread register.  Between the point the
|> > thread is created and inserted in the list of active threads, and the
|> > point the thread register is initialized in the child a cancel signal may
|> > arrive, with the thread manager calling pthread_handle_exit.
|> ...
|> > To fix this race I have blocked the cancel signal in the manager around
|> > the clone call, so that the child does not call the signal handler before
|> > thread_self is initialized.
|> 
|> Wouldn't it be enough to check for this special case in
|> pthread_handle_sigcancel(), like so:
|> 
|> static void pthread_handle_sigcancel(int sig)
|> {
|>   pthread_descr self = thread_self();
|>   sigjmp_buf * jmpbuf;
|> 
|>   if (self == &__pthread_manager_thread)
|>     {
|>       if (thread_self_stack() == &__pthread_manager_thread)
|>         {
|> 	  __pthread_manager_sighandler(sig);
|>           return;
|>         }
|>       /* Oops, thread_self() isn't working yet..  */
|>       self = thread_self_stack();
|>     }
|> ...
|> 
|> with thread_self_stack() being the current 'normal' thread_self().

Would this thread_self_stack work with FLOATING_STACKS?  What if the stack
size of the new thread is wildly different from STACK_SIZE?  I don't think
that thread_self_stack can always return a valid thread descriptor.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5