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 __pthread_manager_adjust_prio 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) __sched_setscheduler (SCHED_OTHER) 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.