Red Hat Bugzilla – Bug 61539
The race condition in linuxthreads
Last modified: 2007-04-18 12:41:03 EDT
There is a race condition between __pthread_manager_adjust_prio
called from pthread_setschedparam and pthread_start_thread on
manager_thread->p_priority. When a thread is calling
pthread_setschedparam, the new thread may inherit SCHED_FIFO from
the manager thread. That is
Thread A calls pthread_setschedparam
calls __sched_setscheduler (SCHED_FIFO) on the manager thread.
The main thread calls pthread_create
The manager threads calls pthread_start_thread. It does
if (manager_thread->p_priority > 0)
Since manager_thread->p_priority may not be changed by
__pthread_manager_adjust_prio yet, the new thread may inherit
SCHED_FIFO. Here is a patch. the worst case is pthread_start_thread
may call __sched_setscheduler (SCHED_OTHER) before
__sched_setscheduler (SCHED_FIFO) is called on the manager thread.
Created attachment 49328 [details]
A simple patch
I don't know if a spinlock for manager_thread->p_priority
is a better fix. Also we need to check if there are any other
race conditions like that for other manager_thread fields.
Created attachment 49329 [details]
A patch with spinlock
I uploaded another patch with spinlock.
I've explained a few times on the libc lists that the patches aren't adequate.
And probably no userlevel solution can be adequate. But this is all pointless
now. LinuxThreads stays as it is, correct or not. I'm closing the bug therefore.