[Bug nptl/14830] New: Race conditions with signals and thread priority scheduling

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14830

             Bug #: 14830
           Summary: Race conditions with signals and thread priority
                    scheduling
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


NPTL implements thread priority scheduling for new threads by creating the new
thread but blocking its forward progress until pthread_create in the parent can
set the new thread's scheduling options. If this fails (e.g. due to EPERM),
pthread_create is required to fail. To achieve this result, NPTL has
pthread_create send a cancellation request to the new thread.

Unfortunately, NPTL fails to block signals during thread creation, so it's
possible that a signal handler is already running (at the wrong priority) in
the newly created thread by the time the failure to set the priority had been
detected. The cancellation request will then cause any cancellation-point
function called from the signal handler to act upon cancellation, possibly with
disastrous results if the application was not written to use cancellation.

I believe the simplest solution to this issue is to block all signals before
clone() is called. In the parent, signals can be unblocked immediately as soon
as clone returns. In the new thread, signals cannot be unblocked until it's
determined that the thread will be allowed to run.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.