> > Btw, this also fixes a bug: your patch did > > + __set_task_state(task, state); > + /* didnt get the lock, go to sleep: */ > + schedule(); > > for the schedule case without holding the mutex spinlock. > > And that seems very buggy and racy indeed: since it doesn't hold the mutex > lock, if the old owner releases the mutex at just the right point (yeah, > yeah, it requires a scheduling event on another CPU in order to also miss > the whole "task_is_current()" logic), the wakeup can get lost, because you > set the state to sleeping perhaps _after_ the task just got woken up. So > we stay sleeping even though the mutex is clear. That is indeed a bug. Peter, why did you need to move __set_task_state down here? The -rt patch does not do this. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
