On 2016/04/09 at 21:29, Peter Zijlstra wrote: > On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote: > >>> In any case, I just realized we do not in fact provide this guarantee >>> (of pointing to a blocked task) that needs a bit more work. >> Current patch calls rt_mutex_adjust_prio() before wake_up_q() the >> wakee, at that moment the wakee has been removed by >> rt_mutex_slowunlock()->mark_wakeup_next_waiter(), from current's >> pi_waiters, rt_mutex_adjust_prio() won't see this wakee, so I think >> this should not be problem. > No, any wakeup after mark_wakeup_next_waiter() will make the task run. > And since we must always consider spurious wakeups, we cannot rely on us > (eg. our wake_up_q call) being the one and only. > > Therefore it is possible and the only thing that stands between us and > doom is the fact that the wake_q stuff holds a task reference. > > But we cannot guarantee that the task we have a pointer to is in fact > blocked.
Does that really matters? the pointer is accessed on behalf of current, and current will call rt_mutex_adjust_prio() very soon to update the right pointer. Also the pointer is used to update current's deadline/runtime, we can restore these params in rt_mutex_setprio() for deboost cases. I just checked current code, it did nothing to restore current's deadline/runtime when deboosting, maybe we can leave this job to future deadline bandwidth inheritance? Regards, Xunlei
